计算机网络常见问题汇总

2021/02/04 计算机网络
如果文章图片无法显示,可尝试配置host:修复Github图片资源无法显示问题

1、OSI七层模型

image.png

image.png

2、TCP和UDP的区别

1.TCP面向连接,UDP无连接。

2.TCP面向字节流(文件传输),UDP是面向报文的,UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对IP电话,实时视频会议等)。

3.TCP首部开销20字节,UDP的首部开销小,只有8个字节。

4.TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付。

5.每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。

6.TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道。

3、TCP如何保证数据的可靠传输的?

image.png

应用数据被分割成TCP认为最适合发送的数据块。

  • 超时重传:当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。TCP给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
  • 流量控制:TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议
  • 拥塞控制:当网络拥塞时,减少数据的发送。
  • 校验和:TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段。TCP的接收端会丢弃重复的数据。

4、TCP三次握手的过程

第一次握手:建立连接时,客户端发送 SYN 包(syn=j)到服务器,并进入 SYN_SEND 状态,等待服务器确认;

第二次握手:服务器收到 SYN 包,必须确认客户的 SYN(ack=j+1),同时自己也发送一个 SYN 包(syn=k),即 SYN+ACK 包,此时服务器进入 SYN_RECV 状态;

第三次握手:客户端收到服务器的 SYN+ACK 包,向服务器发送确认包 ACK(ack=k+1),此包发送完毕,客户端和服务器进入 ESTABLISHED 状态,完成三次握手。

image

image

SYN:同步序号,用于建立连接过程

ACK:确认序号标志,为1时表示确认号有效,为0表示报文中不含确认信息,忽略确认号字段

5、为什么是三次握手,不是两次或者四次?

两次握手情况

两次握手有这样一个问题:客户端发出的无效请求在网络中滞留(新的请求代替了旧的)

比如说:

如果网络状况不好,客户端发送了两次请求,第二次请求建立连接成功,并在数据传送完之后释放连接,此时第一次请求恰好传送到了客户端

如果是两次握手就会发生下面的情况:

服务端因为接受到了请求,进行回复,两次握手完成,连接建立。但此时客户端并没有请求连接,并不会理睬服务端的确认。

这样就会造成一种结果:客户端并不会向服务端请求数据,服务端等待客户端请求数据,,会造成服务端资源的浪费

如果采用了三次握手呢?

  • 服务端在响应了滞留在网络中的无效的请求后,向客户端发送了确认信息, //(B—->A)
  • 但是此时客户端已经没有了建立连接的需求,所以并不会响应服务端, // (A不理会B)
  • 服务端因没有接受到客户端的进一步的确认所以连接不会建立 //(建立连接失败)

四次握手情况

  1. A 发送同步信号SYN + A’s Initial sequence number
  2. B 确认收到A的同步信号,并记录 A’s ISN 到本地,命名 B’s ACK sequence number
  3. B发送同步信号SYN + B’s Initial sequence number
  4. A确认收到B的同步信号,并记录 B’s ISN 到本地,命名 A’s ACK sequence number·

很显然2和3 这两个步骤可以合并,只需要三次握手,可以提高连接的速度与效率。

5-1、SYN底层攻击原理

image

客户端只发送SYN包,而对服务器的ACKSYN包不回复,通过模拟大量IP,同时发送这样的请求,导致服务器端SYN-RCVD状态(放置于半连接队列)的连接过多,半连接队列大于系统设定的最大值,系统不再接受其他连接。

简单来讲,就是黑客制造大量客户端同时不进行第二次握手的异常连接,把服务器半连接队列撑爆了,没法接受其他正常连接

6、TCP四次挥手

image

TCP连接是全双工的,因此每个方向都必须单独进行关闭。

1.客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送,并发送一个自己的ISN(u)

2.服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(u+1)。同时发送一个自己的ISN(v)

3.服务器B关闭与客户端A的连接,发送一个FIN、ACK给客户端A,确认号为收到的序号加1(u+1),与上一次不变。同时发送一个自己的ISN(w)

4.客户端A发送ACK报文确认,并将确认序号设置为收到序号加1(w+1),序列号就是上一次的确认号(u+1)

7、为什么是四次挥手

等待服务端未发送的数据传送完毕

** **

详细解释:

如果客户端想要停止向服务端发送数据,首先要停止发送数据,并且通知对方,第二步是等待服务器的回复。当然,服务器要向客户端停止发送数据,也得类似。

四次挥手是因为 TCP 是全双工的,两端能同时向对方发送数据,如果不足四次的话无法确定双方都没有数据发送了。

7-1、服务器TIME_WAIT状态过多

大量TIME_WAIT造成的影响:

​ 在高并发短连接的TCP服务器上,当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高,此时部分客户端就会显示连接不上。

我来解释下这个场景。主动正常关闭TCP连接,都会出现TIMEWAIT。

为什么我们要关注这个高并发短连接呢?有两个方面需要注意:

\1. 高并发可以让服务器在短时间范围内同时占用大量端口,而端口有个0~65535的范围,并不是很多,刨除系统和其他服务要用的,剩下的就更少了。

\2. 在这个场景中,短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接

​ 这里有个相对长短的概念,比如取一个web页面,1秒钟的http短连接处理完业务,在关闭连接之后,这个业务用过的端口会停留在TIMEWAIT状态几分钟,而这几分钟,其他HTTP请求来临的时候是无法占用此端口的(占着茅坑不拉翔)。

单用这个业务计算服务器的利用率会发现,服务器干正经事的时间和端口(资源)被挂着无法被使用的时间的比例是 1:几百,服务器资源严重浪费。(说个题外话,从这个意义出发来考虑服务器性能调优的话,长连接业务的服务就不需要考虑TIMEWAIT状态。同时,假如你对服务器业务场景非常熟悉,你会发现,在实际业务场景中,一般长连接对应的业务的并发量并不会很高

综合这两个方面,持续的到达一定量的高并发短连接,会使服务器因端口资源不足而拒绝为一部分客户服务。同时,这些端口都是服务器临时分配,无法用SO_REUSEADDR选项解决这个问题。

相关参数优化调整(当然得根据服务器的实际情况配置,这里着重讲参数意义):

既然知道了TIME_WAIT的用意了,尽量按照TCP的协议规定来调整,对于tw的reuse、recycle其实是违反TCP协议规定的,服务器资源允许、负载不大的条件下,尽量不要打开,当出现TCP: time wait bucket table overflow,尽量调大下面参数:

  • 调大time_wait队列数
  • 减小TIME_WAIT_2到TIME_WAIT的超时时间
  • 修改系統默认的TIMEOUT时间

vim /etc/sysctl.conf

#time wait 最高的队列数
tcp_max_tw_buckets = 256000

调整次参数的同时,要调整TIME_WAIT_2到TIME_WAIT的超时时间,默认是60s,优化到30s:

net.ipv4.tcp_fin_timeout = 30

其它TCP本身的配合参数类似与synack重传次数、syn重传次数等以后介绍,优化后也是有所益处的。

#修改系統默认的TIMEOUT时间
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse = 1

7-2、服务器CLOSE_WAIT状态过多

常见原因:数据库连接没有close()

今天在运行服务器的时候发现一个问题,问题的表现是客户端一直在请求,但是返回给客户端的信息是异常,服务端压根没有收到请求,查看了一下配置信息没有错误,首先查看了一下是不是服务器的连接已经满了,打开netstat命令发现服务器的连接有 大量的CLOSE_WAIT状态的socket,没怎么遇到这个问题,开始还真有段懵了,第一反应就是是不是客户端的问题(是不是出问题的第一反应都是别人的问题),但是马上补充了一下socket状态机的知识,发现这个状态是由于客户端关闭了socket连接,发送了FIN报文,服务端也发送了ACK报文,此时客户端处于FIN_WAIT_2状态,服务端处于CLOSE_WAIT状态,如下图:

image

可以看出,出现问题的原因是由于我这边没有发送第二个FIN报文导致的,分明是我的问题啊,为什么服务器没有发送FIN报文呢?我的服务器使用的是嵌入式的jetty,连接管理应该都是它帮我管理的,重启了一下服务器发现服务器的CLOSE_WAIT开始的时候没有出现,之后逐渐的上升,貌似随着请求的数量逐渐增长的,而我这边的日志也非常奇怪,我会在收到请求的时候打印日志,然后在执行完毕的时候输出一个accesslog信息,发现日志中有入口的请求日志,但是accessLog没有增长,于是单步调试了一下,发现了问题:一个servlet的执行走到主流程就走不下去了,阻塞在数据库访问那一步上,具体表现就是获取不到数据库连接!

查看了一下代码,发现原来是自己创建连接,执行sql,完成之后没有关闭连接,OMG,这么愚蠢的错误,于是在所有的数据库操作的最后加上如下的代码:

finally {
    DbUtils.closeQuietly(conn);
}

1、代码一定要规范,尤其是在写一些关于自愿申请的部分,一定要在写函数之前写上注释告诉自己别忘了释放资源。

2、数据库连接和访问要设置超时时间,避免阻塞。

8、DNS域名系统工作原理

1.查询 浏览器、操作系统 缓存。

2.请求 本地域名服务器

3.本地域名服务器未命中缓存,其请求 根域名服务器

4.根域名服务器返回所查询域的主域名服务器。(主域名、顶级域名,如com、cn)

5.本地域名服务器请求主域名服务器,获取该域名的 名称服务器(域名注册商的服务器)。

6.本地域名服务器向 名称服务器 请求 域名-IP 映射。

7.缓存解析结果

9、ARP地址解析协议工作原理

每台主机都有一个ARP列表,存放IP地址和MAC地址的对应关系。

当源主机向目标主机发送数据时,首先查看ARP列表中IP地址对应的目标主机的MAC地址,如果找到则直接发送数据;如果找不到,就向该网段中的所有主机发送ARP请求包,里面存放源IP地址,源MAC地址,目标IP地址。

当该网段中的所有主机收到该ARP响应包之后,首先查看目标ip地址是否与自己相匹配,如果不是则忽略,如果是,就将源ip地址和源MAC地址存放到自己的ARP列表中,然后将自己的MAC地址存放到ARP响应包中发送给源主机;

目标主机收到ARP响应包,则取出对应的IP和MAC地址存放到ARP列表中,并发送数据。若未收到则ARP查询失败。

广播ARP请求,单播ARP响应。

10、连续ARQ和滑动窗口协议

连续ARQ协议:所谓连续就是在发送完一个数据帧后,不是停下来等待确认帧,而是可以连续再发若干帧,边发可以边等待确认帧,如果收到了确认帧,又可以继续发送数据帧, 由于减少了等待的时间,利用率就提高了。

但是连续ARQ在收到一个否认帧或超时后,所有该帧后面的帧都要重发而不管该帧后面的帧是否正确传送 于是便有了选择重传ARQ协议。

滑动窗口协议:允许发送方发送多个分组而不需等待确认。(滑动窗口协议是TCP使用的一种流量控制方法,此协议能够加速数据的传输)

11、HTTP和HTTPS的区别

  • HTTP协议时超文本传输协议。
  • HTTPS是安全的超文本传输协议,是安全版的HTTP协议,使用安全套接字层(SSL)进行信息交换。

HTTPS协议主要针对解决HTTP协议以下不足:

1.通信使用明文(不加密),内容可能会被窃听

2.不验证通信方身份,应此可能遭遇伪装

3.无法证明报文的完整性(即准确性),所以可能已遭篡改

HTTP+加密+认证+完整性保护=HTTPS

HTTP端口 80

HTTPS端口443

HTTPS采用对称加密

SSL位于应用层于传输层TCP之间,原本数据由应用层直接交由传输层处理,现在会经过SSL加密再进行传输。

HTTPS也不是绝对安全的,针对SSL的中间人攻击方式主要有两类,分别是SSL劫持攻击和SSL剥离攻击。

SSL劫持攻击就是 SSL证书欺骗攻击,将自己接入到客户端和目标网站之间; 在传输过程中伪造服务器的证书,将服务器的公钥替换成自己的公钥。

12、在浏览器中输入url地址 –>显示主页的过程

image

13、HTTP请求方法有哪些,用过哪些?

GET、POST、DELETE image

14、IP地址的分类

A类地址(1~126):网络号占前8位,以0开头,主机号占后24位。

B类地址(128~191):网络号占前16位,以10开头,主机号占后16位。

C类地址(192~223):网络号占前24位,以110开头,主机号占后8位。

D类地址(224~239):以1110开头,保留位多播地址。

E类地址(240~255):以1111开头,保留位今后使用。

image


公众号:豆仔gogo

golang、算法、后端知识、面试手册

豆仔gogo

Search

    公众号:豆仔gogo

    豆仔gogo

    Post Directory