自由意志

黑人夏川

Linux操作系统面试题（2）——网络

发表于 更新于 分类于

1. TCP 三次握手四次挥手过程

三次握手过程

  1. 第一次握手：客户端向服务器端发送连接请求报文段，包含自身数据通讯初始序号，进入SYN-SENT状态。
  2. 第二次握手：服务器端收到连接请求报文段后，如果同意，发送应答，包含自身数据通讯初始序号，进入SYN-RECEIVED状态。
  3. 第三次握手：客户端收到应答，最后向服务器端发送确认报文，进入ESTABLISHED状态，此时成功建立长连接。

四次挥手过程

  1. 首先第一次挥手：客户端认为数据发送完毕，需要向服务器端发送连接释放请求。
  2. 第二次挥手：服务器收到连接释放请求，告诉应用层释放TCP连接。然后发送ACK包，进入CLOSE-WT状态，此时表明客户端到服务器端的连接已经释放，不再接受客户端的数据。因为TCP是全双工的，所以服务器仍可以发送数据。
  3. 第三次挥手：当服务器端数据发送完毕，向客户端发送连接释放请求，进入LAST-ACK状态。
  4. 第四次挥手：客户端收到连接释放请求，向服务器端发送确认应答报文，此时客户端进入TIME-WT状态，持续2倍的MSL（最长报文段寿命），若期间没有收到服务器端的数据报文，进入CLOSED状态。服务器端收到确认应答后，也进入CLOSED状态。

加分回答

以下是客户端向服务器端发起TCP连接的详细过程

  1. 客户端和服务器端刚开始都是处于CLOSED（关闭）状态。
  2. 要注意的是客户端主动打开连接，而服务器端是被动打开连接的。
  3. 服务器端的进程先创建TCB（传输控制块）准备接受客户端的连接请求。
  4. 客户端的进程也是先创建TCB（传输控制块），然后向服务器端发出连接请求报文段，这个报文段中的同步位SYN置为1，同时选择一个初始序号seq=x。TCP协议规定了SYN=1的报文段不可以携带数据，但是要消耗掉一个序号。这个时候客户端进入SYN-SENT状态。
  5. 服务器端收到连接请求报文之后，如果同意连接，就给客户端发送确认响应。在确认报文中应该将同步位SYN和ACK都置为1，而确认号是ACK+1。这时候服务器端也需要给自己选一个初始序号seq=y。值得注意的是这个确认报文也不能携带数据，同样要消耗掉一个序号。这时服务器端进入SYN-RECEIVED状态。
  6. 客户端进程收到服务器端的确认报文，最后还要向服务器端给出确认。确认报文段的ACK置为1，确认号是y+1，而自己的序号seq=x+1。TCP标准规定，ACK报文段可以携带数据，但是如果不携带数据就不消耗序号。在这个情况下，下一个数据报文的序号仍然是seq=x+1。到这时，TCP连接已经成功建立，A进入ESTABLISHED（已建立连接）状态。 到此TCP连接三次握手的过程就全部结束了。
  7. 但是为什么一定要三次握手而不是两次，为什么客户端最后还需要发送一次确认报文呢？其实主要是为了防止已经失效的连接请求报文突然又被传送给了服务器端，然后产生错误。
    1. 假设现在有一种情况，客户端发出的第一个连接请求报文段并没有丢失而是在某些网络节点上被滞留了，直到客户端和服务器端的新连接已经释放后的某个时间点，第一个连接请求报文段才到了服务器端，这时候服务器端以为客户端又发起了一次请求，于是服务器端向客户端发起了确认连接报文段，同意连接。假设不采用三次握手，这时候连接已经建立了，但是客户端并不知道这个情况，服务器端会一直等待客户端的数据报文，这样服务器端的资源就会被浪费，占用大量的资源。所以采用三次握手可以防止这种现象，保护网络和系统资源。 TCP连接释放的过程比较复杂，客户端和服务器端都可以主动释放连接。

下面是从客户端主动释放连接为例讲解四次挥手的详细过程

  1. 客户端的应用进程先向TCP发出一个连接释放报文段，然后停止发送数据报，主动关闭TCP连接。客户端需要将连接释放报文段首部的终止控制FIN置为1，序号设置为u，u相当于前面传输的数据报文段的最后一个字节的序号加1。这时候客户端进入FIN-WT-1（终止等待1）状态，等待服务器端的确认。需要注意的是，FIN报文段也是即使不携带数据，它也消耗一个序号。
  2. 服务器在收到客户端发来的连接释放报文段请求之后就发出确认，确认号ack=u+1，这个报文段自己的序号是v，v相当于之前已经传送出去的最后一个报文段的序号加1。这时候服务器端进入CLOSE-WT（关闭等待）状态，这时候服务器端的TCP进程就要通知应用进程，客户端到服务器端的连接已经关闭了。需要注意的是，这个时候的TCP连接就处于一个半关闭（half-colse）的状态，尽管客户端已经没有数据要发送了，但是服务器端还是可以向客户端发送数据的，服务器端到客户端的连接并没有被释放掉。
  3. 如果服务器端也没有数据要发送给客户端了，那么应用进程就通知TCP释放连接。这时候服务器端发出的连接释放报文段请求的终止指令FIN也置为1。这时候服务器端的序号已经是w了，因为在半关闭状态服务器端可能又发送了一些数据，服务器也必须重复上次已经发送过的确认号ack=u+1。这时候服务器端进入LAST-ACK（最后确认）状态，等待客户端的确认。
  4. 客户端收到服务器端的连接释放请求报文段之后，必须发出确认。在确认报文段中把ACK置为1，确认号ack=w+1，而自己的序号是seq=u+1（根据TCP标准，FIN消耗了一个序号），然后进入TIME-WT（时间等待）状态，这时候连接并没有释放掉，必须等到2倍的MSL（最长报文段寿命）之后，连接才会释放。

2. TCP 和 UDP 的区别

首先 UDP 协议和 TCP 协议都是运输层协议，都是为应用层程序服务，都具有复用（不同的应用层协议可以共用 UDP 协议和 TCP 协议）和分用（将数据报解析之后分发给不同的应用层程序）的功能。

UDP 提供面向无连接基于数据报的不可靠传输，TCP 提供面向连接基于字节流的可靠传输。UDP 在很多实时性要求高的场景有很好的表现，而 TCP 在要求数据准确、对速度没有硬性要求的场景有很好的表现。

加分回答

具体的区别详细描述可以是：

UDP协议

面向无连接（不需要三次握手和四次挥手）、尽最大努力交付、面向报文（每次收发都是一整个报文段）、没有拥塞控制不可靠（只管发不管过程和结果）、支持一对一、一对多、多对一和多对多的通信方式、首部开销很小（8字节）。

  1. 优点是快，没有TCP各种机制，少了很多首部信息和重复确认的过程，节省了大量的网络资源。
  2. 缺点是不可靠不稳定，只管数据的发送不管过程和结果，网络不好的时候很容易造成数据丢失。又因为网络不好的时候不会影响到主机数据报的发送速率，这对很多实时的应用程序很重要，因为像语音通话、视频会议等要求源主机要以恒定的速率发送数据报，允许网络不好的时候丢失一些数据，但不允许太大的延迟，UDP很适合这种要求；

TCP协议

是TCP/IP体系中非常复杂的一个协议，面向连接（需要三次握手四次挥手）、单播（只能端对端的连接）、可靠交付（有大量的机制保护TCP连接数据的可靠性）、全双工通讯（允许双方同时发送信息，也是四次挥手的原由）、面向字节流（不保留数据报边界的情况下以字节流的方式进行传输，这也是长连接的由来。）、头部开销大（最少20字节）。

  1. 优点是可靠、稳定，有确认、窗口、重传、拥塞控制机制，在数据传完之后，还会断开连接用来节约系统资源。
  2. 缺点是慢，效率低，占用系统资源高，在传递数据之前要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接。在要求数据准确、对速度没有硬性要求的场景有很好的表现，比如在FTP（文件传输）、HTTP/HTTPS（超文本传输），TCP很适合这种要求。

3. TCP 和 UDP 的使用场景

  1. UDP的优点是快，没有TCP各种机制，少了很多首部信息和重复确认的过程，节省了大量的网络资源。缺点是不可靠不稳定，只管数据的发送不管过程和结果，网络不好的时候很容易造成数据丢失。又因为网络不好的时候不会影响到主机数据报的发送速率，这对很多实时的应用程序很重要，因为像语音通话、视频会议等要求源主机要以恒定的速率发送数据报，允许网络不好的时候丢失一些数据，但不允许太大的延迟。DNS和ARP协议也是基于UDP实现的，要求快速获取IP、MAC地址，如果基于TCP那么对整个因特网的资源占用过大且速度慢。还有游戏应用程序也是通过UDP来传输报文段，允许出现丢帧导致的卡顿，但是对游戏的整体体验不会产生严重的影响。所以UDP在语音、视频、寻址、游戏、广播方面有很好的应用前景，实时性高，允许部分的数据丢失；
  2. TCP的优点是面向连接提供可靠交付，即对数据有保证、无差错的进行运输。当需要数据准确无误的运输给对方时，如浏览器中需要获取服务器资源使用的HTTP/HTTPS协议，需要保证文件准确、无差错，邮件服务器中使用的SMTP协议，保证邮件内容准确无误的传递给对方，或者是大型应用程序文件，这些都要保证文件的准确、无差错的运输给对方，所以一定要基于TCP来运输，而不是UDP；
  3. 加分回答
    1. UDP的应用场景是根据它的部分特性决定的，如下：
      1. 面向无连接 - 尽最大努力交付；
      2. 面向报文 - 一对多；
    2. TCP的应用场景是根据它的部分特性决定的，如下：
      1. 面向连接 - 单播，一对一 - 可靠交付（确认机制、重传机制、流量控制、拥塞控制等）；

4. TCP 如何实现可靠传输

可靠传输就是通过TCP连接传送的数据是没有差错、不会丢失、不重复并且按序到达的。

TCP是通过序列号、检验和、确认应答信号、重发机制、连接管理、窗口控制、流量控制、拥塞控制一起保证TCP传输的可靠性的。

加分回答

可靠传输的具体实现是：

  1. 应用层的数据会被分割成TCP认为最适合发送的数据块。
  2. 序列号：TCP给发送的每一个包都进行编号，接收方对数据包进行排序，把有序数据传送给应用层，TCP的接收端会丢弃重复的数据。
  3. 检验和：TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。 - 确认应答：如果收到的数据报报文段的检验和没有差错，就确认收到，如果有差错，TCP就丢弃这个报文段和不确认收到此报文段。
  4. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
  5. 拥塞控制：当网络拥塞时，减少数据的发送。
  6. 停止等待协议：它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
  7. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

5. TCP超时重传机制，时间是多少

TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息。接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。

加分回答

影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO）。RTO的值被设置过大过小都会对协议造成不利影响。如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失，降低了连接数据传输的吞吐量。另一方面，若RTO过小，发送端尽管可以很快地检测出报文段的丢失，但也可能将一些延迟大的报文段误认为是丢失，造成不必要的重传，浪费了网络资源。 TCP协议使用自适应算法以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能（即传输时延），由此每一个TCP连接推算出合适的RTO值，当连接时延性能变化时，TCP也能够相应地自动修改RTO的设定，以适应这种网络的变化。 TCP协议采用自适应算法记录数据包的往返时延，并根据往返时延设定RTO的取值。一般来说，RTO的取值会略大于RTT以保证数据包的正常传输。RFC[2988]中建议RTO的计算方式为： RTO = RTTs + 4xRTTd 其中RTTs为加权平均往返时间，RTTd是偏差的加权平均值。 第一次测量往返时间时，SRTT值就取所测量到的RTT样本值，但以后每测量到一个新的往返时间样本，就按下面的式子重新计算一次平滑往返时间SRTT： SRTT = α ×（旧SRTT）+（1-α）×（新RTT）

6. TCP 的流量控制

一般都希望数据能传输得越快越好，但是如果发送方把数据发送得过快，接收方可能就来不及接受到所有的数据，中间可能会丢失数据报。而流量控制就是让发送方的发送速率不要过快，让接收方来得及接收所有的数据，利用滑动窗口这个机制可以很方便的实现在TCP连接上控制对方发送数据报的速率。例如：客户端和服务器端建立TCP连接的时候，客户端告诉服务器“我的接收窗口，rwnd= 400”，这时候服务器端的发送窗口发送的数据报总大小不能超过客户端给出的接收窗口的数值，这里要注意的是，这个数值的单位是字节，而不是报文段。当客户端可以继续接收新的数据报时，发送ACK=1 ack=（上一个报文段序号）+1 rwnd = 100，再接收100个字节的数据报。

7. HTTP 和 HTTPS 的区别

由于HTTP简单快速的特性，当客户端向服务器端请求数据的时候，只需要传送请求方法和路径就可以取到结果，基于TCP，默认端口号为80，耗时可以简略计算为1RTT，传递的数据全部是明文传输，几乎没有安全性。

HTTPS是基于TLS的，而TLS又基于TCP，当客户端向服务器端请求数据的时候，服务器大概率会将客户端重定向到该服务器的443端口，进行新的TCP连接，此时服务器会返回一个证书文件，而不是响应报文体。此时客户端验证证书文件紧接创建对称密钥，之后重新和服务器建立TLS连接，当服务器返回ACK确认之后，连接正式建立，此时上方整个过程耗时为3RTT，并且之后和服务器的通信数据都是通过对称密钥加密过的，几乎无法破解。

HTTP和HTTPS的不同点总结如下

  1. HTTP是基于TCP的，而HTTPS是基于TLS的；
  2. HTTP的往返时间为1RTT，而HTTPS的往返时间为3RTT；
  3. HTTP只需要创建一次TCP连接，而HTTPS需要创建两次TCP连接；
  4. HTTP的默认端口号为80，而HTTPS的默认端口号为443；
  5. HTTP的安全性很差，而HTTPS的安全性很强；

加分回答

HTTPS虽然在安全方面有很大的优势，但是缺点也很明显，如下：

  1. HTTPS握手阶段耗费时间，几乎是HTTP的数倍，会延长页面的首次绘制时间和增加耗电；
  2. HTTPS的效率没有HTTP高，如果部分数据内容实际上并不需要加密，会平白浪费计算机资源；
  3. HTTPS的证书需要购买，功能越强大的证书价格更高；
  4. TTPS的加密并不能阻止某些网络攻击，如黑客攻击、拒绝服务攻击等；

8. HTTPS

HTTPS（Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的HTTP通道，在HTTP的基础上通过身份认证和传输加密阶段保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入TLS（Transport Layer Security 安全传输层协议）/SSL（Secure Sockets Layer 安全套接层协议），HTTPS 的安全基础是 TLS/SSL，因此加密就需要TLS/ SSL。 SSL的全称为Secure Sockets Layer，安全套接层协议。是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL。 TLS的全称是Transport Layer Security，安全传输层协议。是SSL3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。 在HTTPS数据传输的过程中，需要用TLS/SSL对数据进行加密，然后通过HTTP对加密后的密文进行传输，可以看出HTTPS的通信是由HTTP和TLS/SSL配合完成的。

特点

  1. 内容加密：混合加密方式，对称加密和非对称加密；
  2. 验证身份：通过证书认证客户端访问的是正确的服务器；
  3. 数据完整性：防止传输的数据被中间人篡改；

9. HTTPS 加解密的过程是怎么样的？

HTTPS数据加解密过程中数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。

HTTPS协议加密的过程可以分为两个阶段，分别是：

  1. 证书的认证阶段：使用非对称加解密算法对数据传送阶段的对称加解密密钥进行加密和解密；
  2. 数据传送阶段：通过证书认证阶段获取到目标服务器的对称加解密密钥，对数据进行加密传送给服务器；

加分回答

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输。总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。 在整个HTTPS数据传输的过程中一共会涉及到四个密钥：

  1. CA机构的公钥，用来验证数字证书是否可信任；
  2. 服务器端的公钥；
  3. 服务器端的私钥；
  4. 客户端生成的随机密钥 一个HTTPS请求可以分为两个阶段，证书认证阶段和数据传送阶段；
  5. 又可以细分为六个步骤：
    1. 客户端第一次向服务器发起HTTPS请求，连接到服务器的443（默认）端口；
    2. 服务器端有一个密钥对，公钥和私钥。用来进行非对称加密使用，服务器端保存私钥，不能泄露，公钥可以发送给任何人。服务器将自己的数字证书（包含公钥）发送给客户端；
    3. 客户端收到服务器端的数字
    4. 证书之后，会对数字证书进行检查，验证合法性。如果发现数字证书有问题，那么HTTPS传输就中断。如果数字证书合格，那么客户端生成一个随机值，这个随机值是数据传输阶段时给数据对称加密的密钥，然后用数字证书中的公钥加密这个随机值密钥，这样就生成了加密数据使用的密钥的密文。到这时，HTTPS中的第一次HTTP请求就结束了；
    5. 客户端第二次向服务器发起HTTP请求，将对称加密密钥的密文发送给服务器；
    6. 服务器接收到客户端发来的密文之后，通过使用非对称加密中的私钥解密密文，得到数据传送阶段使用的对称加密密钥。然后对需要返回给客户端的数据通过这个对称加密密钥加密，生成数据密文，最后将这个密文发送给客户端；
    7. 客户端收到服务器端发送过来的密文，通过本地密钥对密文进行解密，得到数据明文。到这时，HTTPS中的第二次HTTP请求结束，整个HTTPS传输完成。

10. HTTP1.x 和 HTTP2.0 的区别是什么？

HTTP1.x和HTTP2.0主要的区别主要HTTP2.0使用了二进制的数据传输方式、多路复用机制、头部缓存和服务器推送特点。

加分回答

HTTP1.x和HTTP2.0主要的区别主要有以下四点：

  1. 二进制格式（Binary Format）：HTTP1.x的解析是基于文本，但是基于文本协议的格式解析存在天然缺陷。文本的表现形式应该具有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮；
  2. 多路复用（MultiPlexing）：连接共享，每一个请求都是是用作连接共享机制的。一个请求对应一个id，这样一个连接上可以有多个请求，每个连接的请求可以随机的混杂在一起，接收方可以根据请求的 id将请求再归属到各自不同的服务端请求里面；
  3. 头部压缩：HTTP1.x的头部带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的头部大小，通讯双方各自缓存一份头部表，既避免了重复头部的传输，又减小了需要传输的大小；
  4. 服务端推送（server push）：如果请求了index.html文件，服务器端会主动将它的依赖文件一起返回。

11. DNS 解析过程以及 DNS 劫持

DNS查询的过程简单描述就是：

  1. 主机向本地域名服务器发起某个域名的DNS查询请求，
  2. 如果本地域名服务器查询到对应IP，就返回结果，
  3. 否则本地域名服务器直接向根域名服务器发起DNS查询请求，要么返回结果，要么告诉本地域名服务器下一次的请求服务器IP地址，
  4. 下一次的请求服务器可能是顶级域名服务器也可能还是根域名服务器，然后继续查询。
  5. 循环这样的步骤直到查询到结果，本地域名服务器拿到结果返回给主机。

在完成整个域名解析的过程之后，并没有收到本该收到的IP地址，而是接收到了一个错误的IP地址。比如输入的网址是百度，但是却进入了奇怪的网址，并且地址栏依旧是百度。在这个过程中，攻击者一般是修改了本地路由器的DNS地址，从而访问了一个伪造的DNS服务器，这个伪造的服务器解析域名的时候返回了一个攻击者精心设计的网站，这个网站可能和目标网站一模一样，当用户输入个人账户时，数据会发送给攻击者，从而造成个人财产的丢失。

加分回答

预防DNS劫持可以通过以下几种方法：

  1. 准备多个域名，当某个域名被劫持时，暂时使用另一个；
  2. 手动修改DNS，在地址栏输入http://192.168.1.1，进入路由器配置，填写主DNS服务器为114.114.114.114，填写备用DNS服务器为8.8.8.8；
  3. 修改路由器密码；
  4. 给运营商打投诉电话，讲明被劫持的情况；