网络(2) - TCP/IP系列-TCP/IP协议

最新推荐文章于 2024-01-18 06:26:01 发布

Andre-S

最新推荐文章于 2024-01-18 06:26:01 发布

阅读量492

点赞数 1

分类专栏： TCP/IP 协议理论文章标签： linux TCP

本文链接：https://blog.csdn.net/vertor11/article/details/102614032

版权

TCP/IP 协议理论专栏收录该内容

18 篇文章 1 订阅

订阅专栏

一. TCP/IP参考模型

1.1 TCP/IP各层的作用

1.2 TCP/IP各层典型协议

二. 应用层

HTTP(80) 超文本传输协议，提供浏览网页服务；
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. 单独的一个字节，代表选项的类型。

2. TLV格式，第一个字节代表选项的类型，紧接着的一个字节代表选项的长度，后面跟着选项的数据。

RFC1323: TCP Extensions for High Performance

        这个 RFC 主要是考虑高带宽高延迟网络下如何提升 TCP 的性能。该 RFC 定义了
        新的 TCP 选项，以实现窗口缩放 (window scaled) 和时间戳 (timestamp)。这里的时间
        戳可以用于实现两个机制： RTTM(Round Trip Time Measurement) 和 PAWS(Protect
        Against Wrapped Sequences)。

        在 RFC1323 中提出，在这类高带宽高延迟网络下，有三个主要的影响 TCP 性能的
        因素：
        窗口尺寸限制: 在 TCP 头部中，只有 16 位的一个域用于说明窗口大小。也就是说，
        窗口大小最大只能达到 216 = 64K 字节。解决这一问题的方案是增加一个窗口缩
        放选项。
        丢包后的恢复: 丢包会导致 TCP 重新进入慢启动状态，导致数据的流水线断流。在
        引入了快重传和快恢复后，可以解决丢包率为一个窗口中丢一个包的情况下的问
        题。但是在引入了窗口缩放以后，由于窗口的扩大，丢包的概率也随之增加。很容
        易使 TCP 进入到慢启动状态，影响网络性能。为了解决这一问题，需要引入 SACK
        机制，但在这个 RFC 中，不讨论 SACK 相关的问题。
        往返时间度量 RTO(Retransmission timeout): 是 TCP 性能的一个很基础的参数。
        在 RFC1323 中介绍了一种名为 RTTM 的机制，利用一个新的名为 Timestamps
        的选项来对时间进行进一步的统计。

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 字节，而 SACK 占据的为 8*n+2, 故而，一
        次通告，最多确认 4 大块。而且 SACK 经常和用于 RTTM 的时间戳一起使用，而时间
        戳占据了 10 各字节，故而，依次通过也就最多确认 3 大块了。

RFC2525: Known TCP Implementation Problems

RFC3168 : The Addition of Explicit Congestion Notification (ECN) to IP

        该 RFC 为 TCP/IP 网络引入了一种新的用于处理网络拥塞问题的方法。在以往的
        TCP 中，人们假定网络是一个不透明的黑盒。而发送方通过丢包的情况来推测路由器处
        发生了拥塞。这种拥塞控制方法对于交互式的应用效果并不理想，且可能对吞吐量造成
        负面影响。因为此时网络可能已经计入到了拥塞状态（路由器的缓存满了，因此发生了
        丢包）。为了解决这一问题，人们已经引入了主动队列管理算法（AQM）。允许路由器在
        拥塞发生的早期，即队列快要满了的时候，就通过主动丢包的方式，告知发送端要减慢
        发送速率。然而，主动丢包会引起包的重传，这会降低网络的性能。因此， RFC3168 引
        入了 ECN（显式拥塞通知）机制。

        在引入 ECN 机制后， AQM 通知发送端的方式不再局限于主动丢包，而是可以通
        过 IP 头部的 Congestion Experienced(CE) 来通知支持 ECN 机制的发送端发生了拥塞。
        这样，接收端可以不必通过丢包来实现 AQM，减少了发送端因丢包而产生的性能下降。

        在 TCP 协议中，利用 TCP 头部的保留位为 ECN 提供了支持。这里规定了两个
        新的位： ECE 和 CWR。 ECE 用于在三次握手中协商手否启用 ECN 功能。 CWR 用于
        让接收端决定何时可以停止设置 ECE 标志。

        对于一个 TCP 连接，一个典型的基于 ECN 的序列如下：
        1. 发送方在发送的包中设置 ECE 位，表明发送端支持 ECN。
        2. 在该包经历一个支持 ECN 的路由器时，该路由器发现了拥塞，准备主动丢包。此
        时，它发现正要丢弃的包支持 ECN。它会放弃丢包，而是设置 IP 头部的 CE 位，
        表明经历了拥塞。
        3. 接收方收到设置了 CE 位的包后，在回复的 ACK 中，设置 ECE 标记。
        4. 发送端收到了一个设定了 ECE 标记的 ACK 包，进入和发生丢包一样的拥塞控制
        状态。
        5. 发送端在下一个要发送的包中设定 CWR 位，以通知接收方它已经对 ECE 位进行
        了相应处理

RFC6937 : Proportional Rate Reduction for TCP

RFC7413 : TCP Fast Open(Draft)

        RFC7413 目前还处于草案状态，它引入了一种试验性的特性：允许在三次握手阶
        段的 SYN 和 SYN-ACK 包中携带数据。相较于标准的三次握手，引入 TFO(TCP Fast
        Open) 机制可以节省一个 RTT 的时间。该 RFC 由 Google 提交，并在 Linux 和 Chrome
        中实现了对该功能的支持。此后，越来越多的软件也支持了该功能。

        TFO 中，最核心的一个部分是 Fast Open Cookie。这个 Cookie 是由服务器生成的，
        在初次进行常规的 TCP 连接时，由客户端向服务器请求，之后，则可利用这个 Cookie
        在后续的 TCP 连接中在三次握手阶段交换数据。

        请求 Fast Open Cookie 的过程为：
        1. 客户端发送一个带有 Fast Open 选项且 cookie 域为空的 SYN 包
        2. 服务器生成一个 cookie，通过 SYN-ACK 包回复给客户端
        3. 客户端将该 cookie 缓存，并用于后续的 TCP Fast Open 连接。
        建立 Fast Open 连接的过程如下：
        1. 客户端发送一个带有数据的 SYN 包，同时在 Fast Open 选项里带上 cookie。
        2. 服务端验证 cookie 的有效性，如果有效，则回复 SYN-ACK，并将数据发给应用
        程序。
        3. 客户端发送 ACK 请求，确认服务器发来的 SYN-ACK 包及其中的数据。
        4. 至此，三次握手已完成，后续过程与普通 TCP 连接一致

Fast Open选项：

3.1.3 TCP状态机

RFC793: Transmission Control Protocol

TCB: 代表TCP控制块。

连接部分分为了主动连接和被动连接。

主动连接是指客户端从 CLOSED 状态主动发出连接请求，进入 SYN-SENT 状态，之后收到服务端的 SYN+ACK 包，进入 ESTAB状态（即连接建立状态），然后回复 ACK 包，完成三次握手。
被动连接是从 listen 状态开始，监听端口。随后收到 SYN 包，进入 SYN-RCVD 状态，同时发送 SYN+ACK 包，最后，收到 ACK 后，进入 ESTAB状态，完成被动连接的三次握手过程。

连接终止的部分也被分为了两部分进行实现，主动终止和被动终止。

主动终止是上图中从 ESTAB 状态主动终止连接，发送 FIN 包的过程。可以看到，主动终止又分为两种情况：
1. 一种是 FIN 发出后，收到了发来的 FIN（即通信双方同时主动关闭连接），此时转入 CLOSING 状态并发送 ACK 包。收到 ACK 后，进入 TIME WAIT 状态。
2. 另一种是收到了 ACK 包，转入 FINWAIT-2 状态，最后收到 FIN 后发送 ACK，完成四次握手，进入 TIME WAIT 状态。最后等数据发送完或者超时后，删除 TCB，进入 CLOSED状态。
被动终止则是接收到 FIN 包后，发送了 ACK 包，进入 CLOSE WAIT 状态。之后，当这一端的数据也发送完成后，发送 FIN 包，进入 LAST-ACK 状态，接收到 ACK后，进入 CLOSED 状态。

3.1.4 TCP/IP 建立和断开会话详解

包含三部分：建立连接，传输数据，断开连接。

三次握手建立连接

第一次握手：Client发生SYN包(seq=x)到Server，并进入SYN_SEND状态，等待Server确认；

第二次握手：Server收到SYN包，确认Client的SYN(ack=x+1)，同时自己也发生一个SYN包(seq=y)，即SYN+ACK包，

此时Server进入SYN_RECV状态；

第三次握手：Client收到Server的SYN+ACK包，向Server发送确认包ACK(ack=y+1)，此包发送完毕，Client和Server进入

ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

数据传输

a. 超时重传

超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq 号数据已经收到。发送方在发送了某个seq包后，等待一段时间，如果没有收到对应的ack回复，就会认为报文丢失，会重传这个数据包。

b.快速重传

接受数据一方发现有数据包丢掉了。就会发送ack报文告诉发送端重传丢失的报文。如果发送端连续收到标号相同的ack包，则会触发客户端的快速重传。比较超时重传和快速重传，可以发现超时重传是发送端在傻等超时，然后触发重传;而快速重传则是接收端主动告诉发送端数据没收到，然后触发发送端重传。

c.流量控制

这里主要说TCP滑动窗流量控制。TCP头里有一个字段叫Window，又叫Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。滑动窗可以是提高TCP传输效率的一种机制。

d.拥塞控制

滑动窗用来做流量控制。流量控制只关注发送端和接受端自身的状况，而没有考虑整个网络的通信情况。拥塞控制，则是基于整个网络来考虑的。考虑一下这样的场景：某一时刻网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，但是，重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，于是，这个情况就会进入恶性循环被不断地放大。试想一下，如果一个网络内有成千上万的TCP连接都这么行事，那么马上就会形成“网络风暴”，TCP这个协议就会拖垮整个网络。为此，TCP引入了拥塞控制策略。拥塞策略算法主要包括：慢启动，拥塞避免，拥塞发生，快速恢复。