TCP/IP知识合集

一、TCP/IP基础

二、ARP原理

三、TCP状态转换图

TCP通信过程包括三个步骤：建立TCP连接通道（三次握手）、数据传输、断开TCP连接通道（四次挥手），如下图：

TCP状态状态转换图如图：

TCP三路握手过程的状态变迁：
CLOSED：起始点，在超时或者连接关闭时候进入此状态，这并不是一个真正的状态，而是这个状态图的假想起点和终点。
LISTEN：服务器端等待连接的状态。服务器经过 socket，bind，listen 函数之后进入此状态，开始监听客户端发过来的连接请求。此称为应用程序被动打开（等到客户端连接请求）。
SYN_SENT：第一次握手发生阶段，客户端发起连接。客户端调用 connect，发送 SYN 给服务器端，然后进入 SYN_SENT 状态，等待服务器端确认（三次握手中的第二个报文）。如果服务器端不能连接，则直接进入CLOSED状态。
SYN_RCVD：第二次握手发生阶段，跟 3 对应，这里是服务器端接收到了客户端的 SYN，此时服务器由 LISTEN 进入 SYN_RCVD状态，同时服务器端回应一个 ACK，然后再发送一个 SYN 即 SYN+ACK 给客户端。状态图中还描绘了这样一种情况，当客户端在发送 SYN 的同时也收到服务器端的 SYN请求，即两个同时发起连接请求，那么客户端就会从 SYN_SENT 转换到 SYN_REVD 状态。
ESTABLISHED：第三次握手发生阶段，客户端接收到服务器端的 ACK 包（ACK，SYN）之后，也会发送一个 ACK 确认包，客户端进入 ESTABLISHED 状态，表明客户端这边已经准备好，但TCP 需要两端都准备好才可以进行数据传输。服务器端收到客户端的 ACK 之后会从 SYN_RCVD 状态转移到 ESTABLISHED 状态，表明服务器端也准备好进行数据传输了。这样客户端和服务器端都是 ESTABLISHED 状态，就可以进行后面的数据传输了。所以 ESTABLISHED 也可以说是一个数据传送状态。
上面就是 TCP 三次握手过程的状态变迁。结合第一张三次握手过程图，从报文的角度看状态变迁：SYN_SENT 状态表示已经客户端已经发送了 SYN 报文，SYN_RCVD 状态表示服务器端已经接收到了 SYN 报文。

TCP四次挥手过程的状态变迁：
FIN_WAIT_1：第一次挥手。主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端，这里以客户端执行主动关闭为例），终止连接时，发送 FIN 给对方，然后等待对方返回 ACK 。调用 close() 第一次挥手就进入此状态。
CLOSE_WAIT：接收到FIN 之后，被动关闭的一方进入此状态。具体动作是接收到 FIN，同时发送 ACK。之所以叫 CLOSE_WAIT 可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。前面已经说过，TCP关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到FIN 后也需要调用 close 关闭，这个 CLOSE_WAIT 就是处于这个状态，等待发送 FIN，发送了FIN 则进入 LAST_ACK 状态。
FIN_WAIT_2：主动端（这里是客户端）先执行主动关闭发送FIN，然后接收到被动方返回的 ACK 后进入此状态。
LAST_ACK：被动方（服务器端）发起关闭请求，由状态2 进入此状态，具体动作是发送 FIN给对方，同时在接收到ACK 时进入CLOSED状态。
CLOSING：两边同时发起关闭请求时（即主动方发送FIN，等待被动方返回ACK，同时被动方也发送了FIN，主动方接收到了FIN之后，发送ACK给被动方），主动方会由FIN_WAIT_1 进入此状态，等待被动方返回ACK。
TIME_WAIT：从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入CLOSED状态。共有三个状态会进入该状态
由CLOSING进入：同时发起关闭情况下，当主动端接收到ACK后，进入此状态，实际上这里的同时是这样的情况：客户端发起关闭请求，发送FIN之后等待服务器端回应ACK，但此时服务器端同时也发起关闭请求，也发送了FIN，并且被客户端先于ACK接收到。
由FIN_WAIT_1进入：发起关闭后，发送了FIN，等待ACK的时候，正好被动方（服务器端）也发起关闭请求，发送了FIN，这时客户端接收到了先前ACK，也收到了对方的FIN，然后发送ACK（对对方FIN的回应），与CLOSING进入的状态不同的是接收到FIN和ACK的先后顺序。
由FIN_WAIT_2进入：这是不同时的情况，主动方在完成自身发起的主动关闭请求后，接收到了对方发送过来的FIN，然后回应 ACK。

TIME_WAIT状态作用：
从上面进入TIME_WAIT状态的三个状态动作来看（可以直接看状态变迁图）都是主动方最后回应一个ACK（CLOSING实际上前面的那个FIN_WAIT_1状态就已经回应了ACK）。
先考虑这样的一个情况，假如这个最后回应的ACK丢失了，也就是服务器端接收不到这个ACK，那么服务器将继续发送它最终的那个FIN，因此客户端必须维护状态信息（TIME_WAIT）允许它重发最后的那个ACK。如果没有这个TIME_WAIT状态，客户端处于CLOSED状态（开头就说了CLOSED状态实际并不存在，是我们为了方便描述假想的），那么客户端将响应RST，服务器端收到后会将该RST分节解释成一个错误，也就不能实现最后的全双工关闭了（可能是主动方单方的关闭）。所以要实现TCP全双工连接的正常终止（两方都关闭连接），必须处理终止过程中四个分节任何一个分节的丢失情况，那么主动关闭连接的主动端必须维持TIME_WAIT状态，最后一个回应ACK的是主动执行关闭的那端。从变迁图可以看出，如果没有TIME_WAIT状态，我们将没有任何机制来保证最后一个ACK能够正常到达。前面的FIN，ACK正常到达均有相应的状态对应。
还有这样一种情况，如果目前的通信双方都已经调用了 close()，都到达了CLOSED状态，没有TIME_WAIT状态时，会出现这样一种情况，现在有一个新的连接被建立起来，使用的IP地址和端口和这个先前到达了CLOSED状态的完全相同，假定原先的连接中还有数据报残存在网络之中，这样新的连接建立以后传输的数据极有可能就是原先的连接的数据报，为了防止这一点，TCP不允许从处于TIME_WAIT状态的socket 建立一个连接。处于TIME_WAIT状态的 socket 在等待了两倍的MSL时间之后，将会转变为CLOSED状态。这里TIME_WAIT状态持续的时间是2MSL（MSL是任何IP数据报能够在因特网中存活的最长时间），足以让这两个方向上的数据包被丢弃（最长是2MSL）。通过实施这个规则，我们就能保证每成功建立一个TCP连接时，来自该连接先前化身的老的重复分组都已经在网络中消逝了。
综上来看：TIME_WAIT存在的两个理由就是

• 可靠地实现TCP全双工连接的终止；
• 允许老的重复分节（数据报）在网络中消逝。

四、MSS

MTU和MSS
MTU：链路层限制的最大传输单元，以太网默认1500字节
MSS：最大报文段长度，是TCP协议的一个选项，用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度（不包括文段头）。

MTU对于tcp传输的影响
tcp传输在三次握手阶段会协商mss，双方取较小一方的mss作为最大数据段大小进行传输，每次从缓冲区中取出不大于mss的数据封装报头进行发送。
因此，tcp在传输层就会自动进行数据分段，而不会再网络层进行数据分片

MTU对于udp传输的影响
udp不受mss约束，只要udp数据大小小于64K–28就可以传输，若udp数据大于MTU，则会在网络层进行数据分片。一旦某一个分片出了问题，这整个报文就会被丢弃。
因此，使用udp传输，程序员最好在上层就按照合适大小进行分包，尽量减少在网络层分片的概率。

五、TCP流量控制

如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

TCP的流量控制通过滑动窗口机制来实现，数据接收端可根据自己的资源情况，随时动态地调整对方的传输窗口大小。

设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值ack。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在ACK=1时确认号字段才有意义。

持续计时器：
当B向A发送了0窗口报文，B此时已经没有空间接受A发送的数据了，通知A停止发送，A在收到后即停止发送。等待一段时间后，B有了一些空间，可以继续接收了，此时再向A发送非0窗口报文。如果此非0窗口报文在网络中丢失,那么A将一直等待非零窗口的通告，B也一直在等待A发来的数据，这样就会造成死锁。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），那么收到这个报文段的一方将当前窗口大小值返回。如果窗口仍是0，重启持续计时器，超时后再发送探测报文段，假设rwnd不为0，则改变发送窗口大小，开始发送报文段。
注意：零窗口探测报文段也有重传计时器，若零窗口探测报文段丢失，当重传计时器超时，零窗口探测报文段会重传

六、TCP拥塞控制

一、拥塞

1.概念：在某段时间，如果对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要发生变化，这种情况叫阻塞
2.拥塞控制：防止过多的数据注入到网络当中，这样可以使网络中的路由器或链路不致过载。（通过拥塞窗口处理网络拥塞现象的一种机制）
3.与流量控制的区别：流量控制往往是指点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接收。
4.拥塞控制的几种方法：慢开始，拥塞避免，快重传，快恢复。

二、慢开始

1.算法原理：当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能因为不清楚当前网络的负荷情况而引起网络阻塞。所以，最好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS的数值。而在每收到一个新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。（慢开始当中的“慢”并不是指cwnd的增长速率慢，而是在TCP开始发送报文段时先设置cwnd = 1,使得发送方在开始时只发送一一个报文段）
注：MSS是TCP数据包每次能够传输的最大数据分段，其中并不包括TCP首部。而MSS只出现在syn报文段当中。一般来说MSS的值在不分段的情况下越大越好（eg:一个外出接口的MSS值时MTU减去IP和TCP首部长度）

2.控制过程：
每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下：

• 当 cwnd < ssthresh 时，使用上述的慢开始算法。
• 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
• 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

三、拥塞避免
1.算法思路：让拥塞窗口cwnd缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口cwnd按线性规律缓慢的增长，比慢开始算法的拥塞窗口增长速率缓慢的多。
无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限（ssthresh）设置为发送窗口的一半（>=2），cwnd设置为1，然后再使用慢启动算法，这样做的目的能迅速的减少网络当中的数据传输，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。

2.控制过程：

• TCP连接初始化，将拥塞窗口cwnd设置为1个报文段，即cwnd = 1;
• 执行慢开始算法，cwnd按指数规律增长，知道cwnd == ssthresh时，开始执行拥塞避免算法，cwnd开始按照线性规律增长；
• 当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，再按照2执行；

例如：
a.在TCP连接进行初始化的时候，cwnd = 1，ssthresh = 16;
b.在慢启动算法开始时，cwnd的初始值是1，每次发送方收到一个ACK拥塞窗口就增加1，当ssthresh == cwnd时，启动拥塞控制算法，拥塞窗口按照线性规律增长；
c.当cwnd = 24时，网络出现超时，发送方收不到确认ACK，此时设置ssthresh = 12,设置cwnd = 1,然后开始慢启动算法，当cwnd = ssthresh=12，慢启动算法变为拥塞控制算法，cwnd按照线性速度增长.

3.AIMD（加法增大乘法减小）：
a.乘法减小：无论在慢启动阶段还是在拥塞控制阶段，只要网络出现超时，就是将cwnd置为1，sthresh置为cwnd的一半，然后开始执行慢启动算法
b.加法增大：当网络频发出现超时情况时，ssthresh就下降的很快，为了减少注入到网络当中的分组数，而加法增大是执行拥塞避免算法后，是拥塞窗口缓慢的增大，以防止网络过早出现拥塞。
这两个结合起来就是AIMD算法，是使用最广泛的算法。拥塞避免算法不能够完全避免网络y拥塞，通过控制拥塞窗口的大小只能使网络不易出现拥塞。

四、快重传
一条TCP连接有时会因为等待重传计时的超时而空闲较长时间，慢开始和拥塞避免无法解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
1.算法过程：快重传算法要求首先接收方收到一个失序的报文段后立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认，如下图：

在上图中，接收方成功的接受了发送方发来的M1,M2并且分别发送了ACK，现在接收方没有收到M3，而收到了M4，显然接收方不能确认M4，因为M4是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到M4,M5等报文段的时候，不断重复的向发送方发送M2的ACK，如果接收方一连收到三个重复的ACK，那么发送方不必等待重传计时器到期，由于发送方尽早重传未被确认的报文段

五：快恢复
1.当发送方连续收到三个重复确认时，执行“乘法减小”算法，慢启动门限减半，为了预防网络发生阻塞。
2.由于发送方现在认为网络很可能没有发生阻塞，因此现在不执行慢启动算法，而是把cwnd值设置为慢启动门限减半后的值，然后开始执行拥塞避免算法，拥塞窗口cwnd值线性增大。

七、拓展

ping

Traceroute
Nagle
TCP发送报文的时机是一个较为复杂的问题。为了提高传输效率，在TCP的实现中广泛使用Nagle算法。算法如下：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对后面的数据先进行写入缓存。只有收到对签名一个报文段的确认后才继续发送下一段报文。

参考：
time_wait状态产生的原因，危害，如何避免
读懂TCP状态转移
【Unix 网络编程】TCP状态转换图详解
*TCP协议
MTU和MSS
Linux内核协议栈中一些关于 TCP MSS 的细节
TCP的拥塞控制（详解）
详解TCP中的拥塞控制
TCP/IP拥塞控制与流量控制