TCP/IP 简单知识点

一. TCP和UCP的区别

TCP是一个面向连接的、可靠的、基于字节流的传输层协议。而UDP是一个面向无连接的传输层协议。

二. TCP三次握手

从最开始双方都处于CLOSED状态。然后服务端开始监听某个端口，进入了LISTEN状态。然后客户端主动发起连接，发送 SYN , 自己变成了SYN-SENT状态。服务端接收到，返回SYN和ACK(对应客户端发来的SYN)，自己变成了SYN-REVD。之后客户端再发送ACK给服务端，自己变成了ESTABLISHED状态；服务端收到ACK之后，也变成了ESTABLISHED状态。

三. TCP挥手

发送后客户端变成了FIN-WAIT-1状态,这时候客户端同时也变成了half-close(半关闭)状态，即无法向服务端发送报文，只能接收。服务端接收后向客户端确认，变成了CLOSED-WAIT状态。客户端接收到了服务端的确认，变成了FIN-WAIT2状态。随后，服务端向客户端发送FIN，自己进入LAST-ACK状态，客户端收到服务端发来的FIN后，自己变成了TIME-WAIT状态，然后发送 ACK 给服务端。
客户端需要等待足够长的时间，具体来说，是 2 个 MSL(Maximum Segment Lifetime，报文最大生存时间), 在这段时间内如果客户端没有收到服务端的重发请求，那么表示 ACK 成功到达，挥手结束，否则客户端重发 ACK。

四.半连接/syn flood(DOS攻击)可能的问题

1. 处理大量的SYN包并返回对应ACK, 势必有大量连接处于SYN_RCVD状态，从而占满整个半连接队列，无法处理正常的请求。
2. 由于是不存在的 IP，服务端长时间收不到客户端的ACK，会导致服务端不断重发数据，直到耗尽服务端的资源。

五. 如何应对 SYN Flood 攻击

1. 增加 SYN 连接，也就是增加半连接队列的容量。
2. 减少 SYN + ACK 重试次数，避免大量的超时重发。
3. 利用 SYN Cookie 技术，在服务端接收到SYN后不立即分配连接资源，而是根据这个SYN计算出一个Cookie，连同第二次握手回复给客户端，在客户端回复ACK的时候带上这个Cookie值，服务端验证 Cookie 合法之后才分配连接资源。

六. TCP 快速打开的原理(TFO)

首先客户端发送SYN给服务端，服务端接收到。现在服务端不是立刻回复 SYN + ACK，而是通过计算得到一个SYN Cookie, 将这个Cookie放到 TCP 报文的 Fast Open选项中，然后才给客户端返回。客户端拿到这个 Cookie 的值缓存下来。后面正常完成三次握手。在后面的三次握手中，客户端会将之前缓存的 Cookie、SYN 和HTTP请求发送给服务端，服务端验证了 Cookie 的合法性，如果不合法直接丢弃；如果是合法的，那么就正常返回SYN + ACK。最显著的改变，三次握手还没建立，仅仅验证了 Cookie 的合法性，就可以返回 HTTP 响应了，客户端最后握手的 ACK 不一定要等到服务端的 HTTP 响应到达才发送，两个过程没有任何关系。

七. TCP流量控制

对于发送端和接收端而言，TCP 需要把发送的数据放到发送缓存区, 将接收的数据放到接收缓存区。流量控制要做的事情，就是在通过接收缓存区的大小，控制发送端的发送。如果对方的接收缓存区满了，就不能再继续发送了。接收端的情况是处理能力不够用，发送端给我少发点，所以此时接收端的接收窗口应该缩小，接收端会在 ACK 的报文首部带上缩小后的滑动窗口字节，发送端对应地调整发送窗口的大小，这也就是流量控制的过程。

八. TCP 的拥塞控制

当前网络特别差，特别容易丢包，那么发送端就应该注意一些了。而这，也正是拥塞控制需要处理的问题。

1. 慢启动
   刚开始进入传输数据的时候，不知道现在的网路到底是稳定还是拥堵的，如果做的太激进，发包太急，那么疯狂丢包，造成雪崩式的网络灾难。
   因此，拥塞控制首先就是要采用一种保守的算法来慢慢地适应整个网路，这种算法叫慢启动.
2. 拥塞窗口:指目前自己还能传输的数据量大小
   步骤:三次握手，双方宣告自己的接收窗口大小,双方初始化自己的拥塞窗口(cwnd)大小,在开始传输的一段时间，发送端每收到一个 ACK，拥塞窗口大小加 1,每经过一个 RTT，cwnd 翻倍。如果说初始窗口为 10，那么第一轮 10 个报文传完且发送端收到 ACK 后，cwnd 变为 20，第二轮变为 40，第三轮变为 80，依次类推。
3. 拥塞避免
   慢启动达到慢启动阈值，拥塞避免起作用，每发完一轮报文且收到ACK后，拥塞窗口只加1，而不是翻倍,慢启动和拥塞避免是一起作用的，是一体的。
4. 快速重传和快速恢复
   1). 快速重传:当发送端收到 3 个重复的 ACK 时，意识到丢包了，于是马上进行重传，不用等到一个 RTO 的时间到了才重传。这就是快速重传，它解决的是是否需要重传的问题。
   2). 选择性重传:在收到发送端的报文后，接收端回复一个 ACK 报文，那么在这个报文首部的可选项中，就可以加上SACK这个属性，通过left edge和right edge告知发送端已经收到了哪些区间的数据报。因此，即使第 5 个包丢包了，当收到第 6、7 个包之后，接收端依然会告诉发送端，这两个包到了。剩下第 5 个包没到，就重传这个包。这个过程也叫做选择性重传(SACK，Selective Acknowledgment)，它解决的是如何重传的问题。
   3). 快速恢复:发送端收到三次重复 ACK 之后，发现丢包，觉得现在的网络已经有些拥塞了，自己会进入快速恢复阶段。在这个阶段，发送端如下改变：拥塞阈值降低为 cwnd 的一半, cwnd 的大小变为拥塞阈值,cwnd 线性增加。

九. Nagle算法:(发送端)

1. 避免小包的频繁发送;
2. 第一次发送数据时不用等待,后面发送满足条件之一就可以发了:1). 数据包大小达到最大段大小(Max Segment Size, 即 MSS); 2). 之前所有包的 ACK 都已接收到

十. 延迟确认:(接收端)

收到发送端的包后，稍稍延迟，然后合并 ACK，最后才回复给发送端。这个延迟一般操作系统实现都不会超过200ms；

十一.keep-alive

作用就是探测对端的连接有没有失效。在 Linux 下，可以这样查看相关的配置:sudo sysctl -a | grep keepalive