网络(2) - TCP/IP系列-TCP/IP协议
- The TCP/IP Guide
- 《TCP那些事》上下集
- 《解析TCP/IP传输层拥塞控制算法——面试热点》
- 《解析TCP/IP协议精华指南——Pdf分享》
- Building Blocks of TCP
一. TCP/IP参考模型
1.1 TCP/IP各层的作用
1.2 TCP/IP各层典型协议
二. 应用层
HTTP(80): 基于网络的通用目的通信协议（World Wide Web），广泛用于网页浏览；
Telnet(23): 提供了一种实现远程终端会话的可靠方法；
FTP(20, 21): 提供了一种基于可靠数据传输机制的安全文件交换方案；
SMTP(25): 采用可靠的数据传递机制实现邮件发送与接收功能；
POP3 (110): 提供了一种基于可靠数据传输实现邮件接收的功能；
TFTP (69)(UDP): 使用统一资源定位技术实现简单可靠的文件传输过程；
三. 传输层
3.1 TCP(传输控制协议) 属于面向连接的网络协议
3.1.1****TCP头部格式
3.1.2 TCP选项 Options
选项总是在TCP头部的最后，且长度是8位的整数倍。格式有两种：
1. 单独的一个字节，代表选项的类型。
TLV格式下，则遵循如下规范：每个数据字段由三个连续的部分构成；其中第一位编码指示类型信息；随后的一位编码表示数据字段长度；剩余部分则承载相应的内容信息。
RFC1323: TCP Extensions for High Performance
该 RFC 主要关注于在高带宽和高延迟的网络环境下优化 TCP 性能，并定义了一个新的 TCP 选项来实现窗口缩放（window scaled）和时间戳（timestamp）。其中的时间戳可用于实施两个机制：RTTM（Round Trip Time Measurement）和 PAWS（Protect Against Wrapped Sequences）。
其中一项重要因素是窗口尺寸限制: 在TCP头部仅限于使用一个16位字段来标识窗口大小。因此, 窗口的最大容量为2^16=64KB.
具体而言, 这意味着只有当在一个window内发送超过该阈值时才允许新的数据发送.
为了改善这一情况可以通过在现有设置基础上增加一个选项来实现窗口缩放.
另一项重要因素是丢包后的恢复: 当数据包丢失时, TCP协议会因重新启动而导致数据传输中断.
然而, 通过引入快速重传机制, 这一问题得到了一定程度的缓解.
RFC1337: TIME-WAIT Assassination Hazards in TCP
在TCP连接过程中存在一个称为TIME_WAIT的阶段，在这个阶段系统将等待2MSL的时间段以便确保所有与当前连接相关的数据包已彻底消失。这样处理后，在尝试再次使用相同端口建立新的连接时就不会出现上一连接遗留的数据仍存在于网络中可能影响新连接的情况。
RFC2018 : TCP Selective Acknowledgement Options
该 RFC 的引入主要是为了解决大规模丢包问题的方法。该机制通过主动确认机制实现接收端会反馈已成功接收的数据段信息；因此发送端只需重新传输那些实际未送达的数据段即可完成有效通信。
该机制采用了两个专门的 TCP 选项字段来实现选择性确认。其中一个用于指示是否支持 SACK 传输（其名称定义为SACKPermitted），该信息只能通过SYN段在连接建立过程中向对方告知。另一个则是在连接已经建立的基础上利用相应的可靠传输控制位来实现对相关传输数据的可靠传输
Sack-Permitted Option:
Sack Option Format:
考虑到传输控制协议（TCP）头部中的选项字段最大容量为40字节；根据计算公式8n+2可知，在此情况下，“一次通告”最多可确认4个大块数据。此外，在实时传输控制协议（RTTM）中通常会同时使用SACK字段和时间戳字段；其中时间戳字段占用了10字节的空间，“依次通过”的次数则会限制最多确认3个大块数据。
RFC2525: Known TCP Implementation Problems
RFC3168 : The Addition of Explicit Congestion Notification (ECN) to IP
该 RFC 为 TCP/IP 网络提供了一种新的解决方案以应对网络拥塞现象。在传统 TCP 协议中，默认将网络视为一个不可知的状态，在这种状态下发送方只能通过观察路由器处是否存在数据包丢失来推断路由器是否处于拥塞状态。然而这种方法对于实时互动型应用效果欠佳，并可能影响数据传输效率因为此时的实际网络状态可能已经发生了变化（例如路由器缓存已满导致立即出现丢包）。针对这一缺陷已有研究者提出了采用主动队列管理算法（AQM）的方法允许路由器在潜在拥塞发生之前就采取行动阻止数据过载从而减少了因过度加载导致的数据丢失问题为此 RFC 3168 引入了显式拥塞通知机制（ECN）。该机制使路由器能够在队列即将饱和时主动丢弃部分数据包从而有效限制了流量的增长进而减少了因过度加载导致的实际拥塞程度
在引入ECN方式后, AQM告知发送层的方式不再仅限于主动丢包行为,而是能够借助IP头部的Congestion Experienced（CE）来告知支持ECN机制的相关发送层其已处于拥塞状态。这样,接收层便无需依赖丢包行为来实现AQM功能,从而降低了发送层因丢包导致的性能下降程度。
在TCP协议中,通过使用TCP头部的保留位实现了对ECN机制的支持.其中设置了两个关键字段:ECE字段和CWR字段.其中,ECE字段负责协调三次握手过程中的ECN功能启用问题.CWR字段则允许接收端自主决定何时解除对ECE字段的设置.
对于一个TCP连接，在该连接建立的一个典型基于ECN的序列如下：
- 发送方会在包含的数据包中置标称标志位（ECE），表明其端口支持ECN协议。
- 当该数据包经过一个支持ECN机制的路由器时，在路由器处会检测到网络拥塞并决定主动丢弃数据包；如果正在丢弃的数据包也支持ECN机制，则会选择不丢弃而设置数据包头部中的确认标志（CE）以表明已感知拥塞状态发生。
- 接收方接收到带有CE标志的数据包后，在响应确认应答（ACK）数据包中会置标称标志位（ECE）。
- 发送方接收到带有ECE标志的ACK数据包后，则会进入与因丢失数据而触发拥塞控制相同的机制状态。
- 在下一个即将发送的数据包中发送方将置重传确认标志（CWR）以通知接收方已经针对CE标志进行了相应处理
RFC6937 : Proportional Rate Reduction for TCP
RFC7413 : TCP Fast Open(Draft)
RFC7413仍处于草稿阶段，并带来了试验性质的功能：支持在三次握手阶段的SYN及SYN-ACK包中嵌入数据内容。通过采用TFO(TCP Fast Open)机制可以减少一个RTT的时间间隔。经Google提交，在Linux和Chrome系统中已实现对此技术的支持。随着更多软件开始采用这一技术方案
TFO 中的关键点在于Fast Open Cookie这一技术。该技术是由服务器生成的，并且在每次需要建立TCP连接时都会被使用。当发起首次常规的TCP连接建立时（即首次尝试通过TCP协议建立连接），客户端会先向服务器发起请求；随后，在后续建立TCP连接的过程中（即后续的一次性连接过程中），双方会在三次握手阶段交换必要的数据。
请求 Fast Open Cookie 的过程如下：
- 客户端发送了一个带有 Fast Open 选项设置但 cookie 字段为空的 SYN 包；
- 服务器生成了一个 cookie ，并通过 SYN-ACK 包反馈给客户端；
- 客户端将此 cookie 存储起来，并用于后续执行 TCP Fast Open 连接流程；
建立 TCP 快速连接的过程如下： - 客户端发送了一个包含数据信息并附加到 Fast Open 选项中的 SYN 包；
- 服务端对 cookie 的有效性进行验证；如果通过验证，则返回一个 SYN-ACK 包，并将接收的数据传输给应用程序；
- 客户端收到服务器返回的确认响应（SYN-ACK）以及相关的传输数据后会发送 ACK 请求
Fast Open选项：
3.1.3 TCP状态机
RFC793: Transmission Control Protocol
TCB: 代表TCP控制块。
- 连接部分分为了主动连接和被动连接。
- 主动连接指的是客户端自发起始的SYN-SENT流程，在CLOSED状态下向服务器发送SYN报文，并触发服务器进入SYN-SENT响应阶段；随后接收服务器发送回的SYN+ACK报文后切换至ESTAB状态（即建立连接的状态），并立即回复ACK报文以完成三次握手。
- 被动连接始于listen状态，在此状态下计算机开始监听指定端口。当接收到一个SYN报文后切换至SYN-RCVD状态，并立即发送一个SYN+ACK报文；当服务器确认接收到该SYN报文并回复ACK报文后，则切换至ESTAB状态（即建立连接的状态），从而完成被动式的SYN-RCVD到ESTAB的状态转换过程。
- 连接终止的部分也被分为了两部分进行实现，主动终止和被动终止 。
主动终止是上图中从 ESTAB 状态开始的主动关闭过程，在此过程中客户端会发送 FIN 包以通知服务器退出连接。这一过程主要包括两种情况：
第一种情况是客户端成功接收到了服务器返回的 FIN 包（即双方均主动关闭连接），此时系统会切换至 CLOSING 状态并发送ACK包；服务器接收到ACK后会进入TIME WAIT状态等待数据传输完成或者出现超时。
第二种情况是客户端在接收ACK包后切换至FINWAIT-2状态，并最终在收到FIN包后发送ACK完成四次握手过程；当数据传输完毕或者发生超时后系统会清除TCB字段并进入CLOSED状态。
被动关闭时会接收到对方发送的FIN包并立即触发CLOSED流程，在此过程中系统会进入CLOSE_WAIT状态等待数据传输结束；当客户端的数据全部发送完毕后会再次向服务器发送FIN包并在接收到ACK响应后切换至CLOSED状态。
3.1.4 TCP/IP 建立和断开会话详解
包含三部分：建立连接， 传输数据， 断开连接。
- 三次握手建立连接
初次通信：Client发送序列号为x的SYN包至Server，并进入SYN_SEND状态以等待服务器的确认；
二次握手：服务器接收到SYN报文；服务器响应客户端发送的SYN报文，并设置ACK字段为x+1；同时，服务器自身也发送了一个新的SYN报文，并设置序列号为y；即形成一个带有SYN和ACK的报文
二次握手：服务器接收到SYN报文；服务器响应客户端发送的SYN报文，并设置ACK字段为x+1；同时，服务器自身也发送了一个新的SYN报文，并设置序列号为y；即形成一个带有SYN和ACK的报文
此时Server进入SYN_RECV状态；
三次握手：Client接收到Server的SYN+ACK报文，并向Server发送acks(ack=y+1)，该acks报文发送完成之后，Client与Server完成通信流程。
ESTABLISHED状态，完成三次握手。
在握手过程中传递的数据包中不包含具体信息内容，在完成三次握手后，在任一方主动关闭其网络连接前阶段内网络连接状态始终保持活跃状态。在最佳情况下，在任一方主动关闭其TCP连接之前，在通信双方之间的TCP连接都将保持持续稳定状态
- 数据传输
a. 超时重传
超时重传机制通过确保TCP传输过程中的可靠通信来提升网络性能。在每次发送数据包的时候，在这些数据报中都会设置编号字段，在接收端接收到这些数据之后将会将接收到的数据报编号返回作为ack确认，并告知具体是哪个编号的数据已经成功接收到位了。当发送方向某个特定的数据包被发送出去之后，在等待一段适当的时间如果并没有得到相应的ack回复就会判断该报文已经丢失从而导致该数据包被重新发送
b.快速重传
接收方检测到数据包传输出现丢失后会立即向发端发送ack报文指示发端进行重传操作。若发端持续接收到标号一致的ack包则会触发收端发起快速重传流程以确保数据完整性。对比两种机制：超时重传是等待超时后主动发起再试；而快速重传则是由收端主动报告未收到数据从而驱动发端执行再试策略
c.流量控制
本文着重讨论的是TCP滑动窗流量控制问题。在TCP协议中，默认附带一个字段名为Window（亦称Advertised-Window）。该字段的作用在于通知发送方当前接收方可用的缓冲空间容量。这样发送方就能依据接方的处理能力适当发量的数据流，并避免接方因过载而被阻塞。滑动窗口机制是一种优化TCP传输效率的有效手段。
d.拥塞控制
滑动窗口用于实现流量控制。流量控制仅关注发送端和接收端的自身状况而不涉及整个网络的通信情况。而拥塞控制则基于整个网络的整体情况进行考虑。设想一下这样一个情景：当某一时刻网络中的传输延迟突然急剧上升时那么TCP协议对这种情况将采取怎样的应对措施呢？TCP对这种情况的处理方式仅仅是重传数据但这种重传行为会导致网络负担加重从而进一步加剧延迟并引发数据丢失增多最终陷入恶性循环不断被放大。如果一个网络内存在数以千计的TCP连接都采取这种行为那么很快就会形成一种大规模的数据洪流即所谓的"网络风暴"在这种情况下TCP协议为了避免网络性能下降因此引入了拥塞控制机制。该机制主要包括以下四个核心算法：慢启动算法、拥塞避免算法、拥塞检测算法以及快速恢复算法
- 四次挥手
第一次挥手：主动关闭方发送一个结束确认报文（FIN），用于终止主动向被动发送数据。这个过程意味着主动关闭一方在发出 FIN 包后不再向被动一方传输任何数据。需要注意的是，在 FIN 包之前传输的数据如果没有对应的 Ack 确认报文，则这些数据会被重新发送。然而，在此之后（即发出 FIN 包之后），主动一方仍然能够接收并处理新的请求。整个过程确保了通信链路在双方均已停止操作后的安全断开。
在两次握手的过程中，在被动一方接收到FIN包之后，在主动一方发送了一个ACK给对方以确认接收方的序列号为接收到的序列号加1（与SYN相同；每个FIN占用一个序列号）
第三次挥手动作：被动关闭方向主动关闭方传递一个FIN指令（ FIN ），其目的是为了指示主动关闭方我的数据已全部发送完毕。
当主动关闭方接收到FIN信号后，在最后一步握手动作中（即第四次挥手），主动关闭方向被动关闭方发送一个ACK报文，并确认接收的序列号为已接收号码加一。至此完成整个握手流程。
3.1.5 滑动窗口
上图中分成了四个部分，分别是：（其中那个黑模型就是滑动窗口）
- #1已接收到acks acknowledgment的数据。
- #2尚未被acks的数据。
- #3在window中尚未发出的数据（接收方仍有存储空间）。
- #4window外的data（接收方无存储能力）。
下面是个滑动后的示意图（收到36的ack，并发出了46-51的字节）：
接受端控制发送端的图示：
3.2 UDP(用户报文协议) 属于无连接的网络协议；
四. 网络层
负责将分组报文自源端发送至目的端；赋予网络设备逻辑地址并处理数据包路由与转发
- IPv4 Packet Format
- IPv6 Packet Format
(Time to live: 用于防环，结合ICMP协议)
- ARP(Address Resolution Protocol) ：广播，不可靠，不安全。MAC地址为全FF。
作用：1. 将IPv4地址解析为MAC地址；2.维护ARP映射的缓存。
IPV6没有了；在LAN中，靠MAC来寻址。
- 工具：Ping(ICMP), Traceroute/Tracer