面向面试学习网络相关知识之一（相关知识）

整理一些网络中经常会被面试到的知识，目录如下

1、TCP的连接建立与释放及其过程

2、三次握手与四次挥手

3、2MSL，是什么东东

4、TCP流量控制：滑动窗口与拥塞控制介绍

5、TCP的首部结构

6、TCP的可靠性保证

7、检验和如何检验数据的正确性

8、TCP与UDP的特点

----------------------------------这是正文的分割线----------------------------------

1、TCP的连接建立与释放的过程

ACK：在TCP中，当发送端的数据到达接收主机时，接收端主机会返回一 个已收到消息的通知。这个消息叫做确认应答，即ACK。

SYN：同步序列编号(Synchronize Sequence Numbers)，在建立连接时用来同步序号

FIN：用来释放一个连接

1）连接建立过程：

第一次握手：建立连接时，客户端发送 syn 包到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到 syn 包，必须确认客户的 SYN，同时自己也发送一个 SYN 包，即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

2）连接释放过程：

第一次挥手：客户端发送一个 FIN，用来关闭客户端到服务器的数据传送，客户端进入FIN_WAIT_1状态。

第二次挥手：服务器收到 FIN 后，发送一个 ACK 给客户端，服务器进入CLOSE_WAIT状态。

第三次挥手：服务器发送一个 FIN ，用来关闭服务器到客户端的数据传送，服务器进入LAST_ACK状态。

第四次挥手：客户端收到 FIN 后，客户端进入TIME_WAIT状态，接着发送一个 ACK 给服务器，服务器进入CLOSED状态，完成四次挥手。

2、TCP三次握手与四次挥手机制

三次握手原因：

为了防止已经失效的连接请求报文段又突然传到服务端，因而产生错误。

A发送的一个连接请求在网络结点的时间滞留，以至于延误到连接释放的某个时间才到达B。B收到这个请求的报文段后，误以为A又发出了一次新的请求连接，于是向A发送确认报文段，同意建立连接。但是由于A并没有发出新的请求连接，所以A不会理睬B的确认也不会向B发送数据。但B却认为连接已经建立，一直等待A发来数据。B的资源就白白浪费了。

注： 首先需要清楚的一点是，三次握手保证了一条信道是可用的，但即使是三次握手或者多次握手不能够确定一条信道是可靠的，因为网费总会到期。

三次握手成功只能说明握手时的通信时正常的。

为什么不是四次握手：三次握手的成功足以说明通信可以正常进行，再试图握手就浪费感情。
为什么不是二次握手：原因详见三次握手原因

四次挥手原因：

由于 TCP 是全双工模式，这就意味着，当主机1发出 FIN 报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；

但是，这个时候主机1还是可以接受来自主机2的数据；

当主机2返回 ACK 报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；

当主机2也发送了 FIN 报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

这个过程中，ACK、FIN 是分开发送的，所以会多一次。

3、在断开连接还要等待的2MSL时间

请注意，第四次挥手后，TCP连接还没有释放掉，品，你细品，断开连接与释放掉。

也就是客户端等待2MSL时间后，才进入CLOSED状态。

时间MSL：最长报文寿命，Maximum Segment Lifetime

为什么呢？

1）为了保证客户端发送的最后一个 ACK 报文段能到达服务器。

这个 ACK 报文段有可能丢失，因而使处在LAST-ACK状态的服务器收不到对已发送的 FIN + ACK 报文段的确认。

服务器会超时重传这个 FIN + ACK 报文段，而客户端就能在2MSL时间内收到这个重传的 FIN + ACK 报文段。

接着客户端重传一次确认，重新启动2MSL计时器。

最后，客户端和服务器都正常进入到CLOSED状态。

如果客户端在TIME-WAIT状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到服务器重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段。

这样，服务器就无法按照正常步骤进入CLOSED状态。

其它问题：MSL的时间大小 -> RFC 793建议设为 2 分钟，当然你也可以不接受

改变这个时间的大小：百度 搜索

4、TCP流量控制：滑动窗口与拥塞控制介绍

流量控制： 所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

1）滑动窗口
作用： 流量控制，是为了防止发送方发送过多的数据而接收方无法接收导致异常

收发消息的两方既有自己的发送窗口也有自己的接收窗口，接收方会先通过TCP协议首部的窗口字段告知发送方自己接收窗口的大小，然后发送方会根据这个大小设置自己发送窗口的大小。

运动规则： 当收到接收方给出的对发送数据的确认之后向右滑动

发送窗口后沿的变化情况2种可能：

a.不动：没有收到确认 ACK。
b.前移:：正常 ACK。

发送窗口前沿的变化情况2种可能：
a.不动
①没有收到新的确认，对方通知的窗口大小不变。
②收到新的确认，但对方通知的窗口缩小。
b.前移：普遍情况。
c.后缩：对方通知窗口缩小。但是TCP不赞成这样子做。

2）拥塞控制


描述： 当数据开始发送时使用的是慢算法，下次传送的数据（以cwnd为单位）翻倍，是指数增长（二倍增长）

当数据达到门限值ssthresh时，改用拥塞避免算法，开始线性增长（只增加1CWND）

直到增长至发生网络拥塞时，发送的数据量会降低到1cwnd

这个时候，就会通过快速恢复算法将发送的数据量恢复到发生网络拥塞时cwnd大小的一半，继续使用拥塞避免算法，发送数据

直到下一次又发生网络拥塞降低到1cwnd时，采用快速恢复算法回复到发生网络拥塞时cwnd的一半

如此循环往复，直至数据发送完毕

5、TCP的首部结构及其作用简述

• 源端口和目的端口：分别写入源端口号和目的端口号，各2字节
• 序号：本报文段所发送的数据的第一个字节的序号，4字节
• 确认号：期望收到对方下一个报文段的第一个数据字节的序号，4字节
• 数据偏移：它指出 TC P报文段的数据起始处距离 TCP 报文段的起始处有多远，占4位
• 保留：保留为今后使用，占6位
• 窗口：窗口值作为接收方让发送方设置其发送窗口的依据，占2字节
• 检验和：检验数据，占2字节
• 紧急指针：指出本报文段中紧急数据的字节数，占2字节
• 选项：用于提高 TCP 的传输性能。长度可变，最长可达40字节

控制位：

• URG：当 URG = 1 时，表明紧急指针有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。
• ACK：仅当 ACK = 1 时确认号才有效。TCP 规定，在建立连接后所有传送的报文段都必须把 ACK 置为 1。
• PSH：当两个应用进程进行交互式的通信时，有时候一端的应用进程希望再键入一个命令后就能立即收到对方的响应。将 PUSH 置 1。
• RST：当 RST = 1 时，表明 TCP 连接中出现严重差错，必须释放连接，再重新建立运输连接；RST = 1 还用来拒绝一个非法的报文段或拒绝打开一个连接。
• SYN：用于建立连接。SYN为1表示希望建立连接，并在其序列号的字段进行序列号初始值的设定。
• FIN：为1时，表示今后不会再有数据发送，希望断开连接。

6、TCP的可靠性保证

1. 检验和
2. 序列号SYN
3. 确认应答ACK
4. 超时重传机制/快速重传机制
   超时重传机制：当报文发出后在一定的时间内未收到接收方的确认，发送发就会进行重传。当数据开始发送时，就会设置一个时间。当这个时间走完未收到接收方发响应，就重传一次。
   快速重传机制： 当发送方发送了M1、M2、M3，其中M3发送失败，又继续发送剩下的数据；而接收方未收到M3，却收到了剩下的数据，这个时候接收只会回复对M2的确认以期收到M3。当发送方收到3个连续的对M2的确认，也就明白了它的M3并没有发送过去，立即快重传M3。
5. 连接管理机制：三握与四挥
6. 滑动窗口
7. 拥塞控制

7、TCP检验和如何检验数据的正确性

TCP首部检验和计算三部分：TCP首部+TCP数据+TCP伪首部。

发送端：
首先，把伪首部、TCP报头、TCP数据分为16位的字，如果总长度为奇数个字节，则在最后增添一个位都为0的字节。把TCP报头中的校验和字段置为0。

其次，用反码相加法（对每16bit进行二进制反码求和）累加所有的16位字（进位也要累加，进位则将高位叠加到低位）。

最后，将上述结果作为TCP的校验和，存在检验和字段中。

接收端：
将所有原码相加，高位叠加到低位， 如计算结果的16位中每一位都为1，则正确，否则说明发生错误。

扩充：UDP检验和
发送端：
首先是将全零放入检验和字段。

再将伪首部以及UDP用户数据报看成是由许多16bit的字串接起来。若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零字节。

然后按二进制反码计算出这些16bit字的和。 将此和的二进制反码写入校验和字段后，发送此UDP用户数据报。

接收端：将收到的UDP用户数据报连同伪首部(以及可能的填充全零字节)一起，按二进制反码求这些16bit字的和。 当无差错时其结果应全为1。否则就表明有差错出现， 接收端就应将此UDP用户数据报丢弃。

8、TCP与UDP的特点

TCP：

1. 面向连接：通信之前必须建立连接。
2. 每一条 TCP 连接只能是点对点的（一对一），连接建立好之后只能连接建立的双方之间进行通信。
3. 提供可靠交付的服务：通过 TCP 连接传输的数据，无差错，不丢失，不重复。保证了数据的安全性。
4. 提供全双工通信。
5. 面向字节流。
6. 首部开销较大，占20字节。

UDP：

1. 无连接。
2. 尽最大努力交付，不保证消息的可靠性 。
3. 面向报文。
4. 无拥塞控制。
5. 支持一对一、一对多、多对一和多对多的交互通信。
6. 首部开销小（只有四个字段：源端口、目的端口、长度、检验和）。