TCP总结和time_wait存在的原因

最新推荐文章于 2024-08-24 20:24:25 发布

Yee Jason

最新推荐文章于 2024-08-24 20:24:25 发布

阅读量377

点赞数

分类专栏：网络编程

本文链接：https://blog.csdn.net/qq_38287952/article/details/104807067

版权

网络编程专栏收录该内容

7 篇文章 1 订阅

订阅专栏

一、tcp介绍

首选，TCP提供客户端与服务器之间的连接。TCP客户端先与某个给定的服务器建立一个连接，在跨该连接与服务器交换数据，然后终止这个连接。

1、tcp提供了可靠性，当tcp向另一端发送数据时，它要求对端返回一个确认，如果没有收到确认，tcp就会自动重新传递数据并等待更长时间，在数次冲传之后，tcp才放弃，如此在尝试发送数据上所花的总时长一般为4-10分钟（依赖具体实现）。

       （1.1）tcp并不保证数据一定会被对方端点接收到，因为这是不可能实现的。如果有可能，tcp就把数据传递到对方端点，否则就（通过放弃重新并中断连接这一手段）通知用户，这么来说，tcp也不能被描述成为100%可靠的协议，它提供的是数据的可靠递送或故障的可靠通知。
   2、tcp含有用于动态估算客户和服务器之间的往返时间（ rtt）算法，以便它知道等待一个确认的时间，举例来说，rtt在一个局域网上大概是几毫秒，跨越一个广域网则可能是数秒钟，另外，因为rtt受网络流通各种变化因素，tcp还持续估计一个给定连接的rtt。
   3、tcp通过给其中每个字节关联一个序列号对所发送的数据进行排序。举例来说，假设一个应用写2048字节到一个tcp套接字，导致tcp发送2个数据包，第一个包所含数据的序列号为1-1024，第二个包所含数据的序列号为1025-2048。如果这些分节非顺序达到，接收端tcp将先根据它们的序列号重新排序，在把结果数据给接受应用。如果接收端tcp接收来自对端的重复数据（比如说对端认为一个分节已丢失并因此重传，而这个分节没有重新丢失，只是由于网络通信过于拥挤），它可以（根据序列号）判断数据是重复的，从而丢弃重复数据。
           udp不提供可靠性，udp本身不提供确认、序列号、rtt估算，超时和重传的机制。如果一个udp数据包在网络中被复制，两份副本就可能都递送到接收端的主机。同样地，如果一个udp客户端发送两个数据包到同一个目的地，他们可能被网络重新排序，颠倒顺序后到达目的地。UDP应用必须处理所有的这些情况。

4、再次，TCP提供流量控制（flow control）。tcp总是告知对端在任何时刻它一次能够从对端接受多少字节的数据，这称之为通告窗口，在任何时候，该窗指出接受缓冲区当前可用的空间量，从而确保发送端发送的数据不会使接受缓冲区溢出。该窗口时刻动态变化，当接受到来发送端的数据时，窗口大小就减少，但是当接收端应用从缓冲区中读取数据时，窗口大小就增大，通知窗口大小减少到0是有可能的：当tcp对应某个套接字的接受缓冲区已满，导致它必须等待应用从该缓冲区读取数据时，方能从对端在接受数据。

udp 不提供流量控制，

5、最后 tcp 连接是全双工的 full -duplex，这意味着在一个给定的连接上应用可以在任何时候在进出两个方向发送数据又接受数据，因此，tcp必须为每个数据流方向跟踪如序列号和通告窗口大小等信息。
udp 可以是全双工的。

二、TCP连接的建立和终止

1、三次握手
(1) 服务器必须准备好接受外来的连接，这通常通过调用socket、bind 和 listen 这三个函数来完成，我们称之为被动打开（passive open）。
（2）客户通过调用 connect 发起主动打开（active open）这导致客户tcp发送一个syn（同步）分节，它告诉服务器客户将在连接中发送的数据的初始序列号，通常syn分接不携带数据，其所在ip数据包只有一个ip首部、一个tcp首部及可能有的tcp选项。
（3）服务端必须确认（ack）客户端的syn, 同时自己也得发送一个syn分节，它含有服务器将在同一连接中发送的数据的初始序列号，服务器在单个分节点中发送syn和对客户端的ack(确认)、
（4）客户端必须确认服务器的syn。

如图。客户端的初始序列号为J，服务器的初始序列号为K，ACK中的确认号是发送这个ack的一端所期待的下一个序列号。因为SYN占据一个字节的序列号空间，所以每一个SYN的ack中的确认号就是该SYN序列号加1，类似的，每一个fin的结束的ack的包的fin的序列号也加1。

三、TCP 选项

每一个SYN可以含有多个TCP选项。下面是常用的TCP选项。

MSS 选项。发送SYN的TCP一端使用本选项通告对端的最大分节大小，既MSS, 也就是它在本连接的每个TCP分节中愿意接受的最大数据量。发送端TCP使用接受端的MSS值作为所发送分节的最大大小。TCP_MAXSEG套接字选项提取和设置这个TCP选项。

窗口规模选项。TCP连接任何一端能够通告对端的最大窗口大小是65535，因为在TCP首部中相应的字段占16位。然而当今因特网上业已普及的高速网络速度要求有更大的窗口获得尽可能大的吞吐量。这个选项指定TCP首部中的窗口必须扩大。因此所提供的最大窗口接近1GB，在一个TCP连接上使用窗口的前提是它的两个端系统必须支持这个选项。我们将使用SO_RCVBUF套接字选项影响这个TCP选项。

为提供与不支持这个选项的较早实现间的互操作性，需应用如下规则，TCP可以作为主动打开的的部分内容随它的SYN发送该选项，但是只在对端也随它的SYN发送该选项的前提下，它才能扩大自己窗口的规模。类似的，服务器的TCP只能接受到随客户端的SYN达到的改选项时，才能发送该选项。

时间戳选项，这个选项对于高速网络连接是必要的，它可以防止失而复现的分组可能造成的数据损坏，它是一个较新的选项，也类似于窗口规模选项的方式协商处理，作为网络编程人员，不需要考虑这个选项。

四、TCP连接终止

TCP建立一个连接需3个分节，终止一个连接需要4个分节。

（1）某个应用进程首先调用close，我们称该端执行主动关闭（active close)，该端的TCP于是发送了一个FIN分节，表示数据发送完毕。

（2）接收到这个FIN的对端执行被动关闭（passive close），这个FIN由TCP 确认。它的接受也作为一个文件结束符（end-of-line），传递给接收端的应用进程（放在已排队等候该应用进程接受的任何其他数据之后），因为FIN的接收意味着接收端的应用在相应的连接上再无额外数据可接受。

（3）一段时间之后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。

（4）接收这个最终的FIN 的原发送端TCP（既执行主动的关闭的那一段）确认这个FIN。

五、TIME_WAIT状态

任何的TCP实现都必须为MSL选择的一个值。 RFC 的建议是2分钟，不过源自Berkeley的实现传统上改用30秒这个值。这意味着TIME_WAIT状态的持续时间在1分钟到4分钟之间。MSL是任何IP数据能够在因特网中存活的时间。我们知道这个时间是有限的，因为每个数据报含有一个称为跳限的 8位字段，它的最大值为255，尽管这是一个跳数限制而不是真正的时间限制，我们仍然假设：最大跳限（255）的分组在网络中存在的时间不可能超过MSL秒。

分组在网络中 “迷途”通常是路由异常的结果。某个路由器崩溃或者两个路由器之前的每个链路断开时，路由协议需要花数秒钟到数分钟的时间才能稳定并找到一条出路。在这段时间内可能发生路由循环（路由器A把分组发送给路由器B，而B在把太慢发送给A), 我们关心的分组可能就此陷入这样的循环。假设迷途的分组是一个TCP分节，在它迷途的期间，发送端TCP超时并重传该分组，而重传的分组却通过某条候选路径达到最终的目的地。然后不久之后（迷途的分组开始其旅程起最多MSL秒以内）路由循环修复，在之前的分组也被重新送到给目的地。这个原来的分组称之为迷途的重复分组或者漫游的重复分组。TCP必须正确处理这些分组。

TIME_WAIT状态有来两个理由存在：

1、可靠地实现TCP全双工连接的中断。

2、允许老的重复分节在网络中消逝。

第一个理由可以看到如上图的最后一个ACK丢失来解释。服务器将重新发送它的最后的FIN，因此客户必须维护状态信息，以允许它重新发送那个ack。要是客户端不维护状态信息，它将相应一个RST (另一种类型的TCP分节)，该分节将被服务器解释成一个错误。如果TCP打算执行所有的工作以彻底终止序列4个分节中任何一个分节丢失的情况。

第二个理由，我们假设在12.106.32.254 的1500端和206.168.112.219的21端口之间有一个tcp连接。如果我们关闭这个连接，不存在TIME_WAIT的状态，过一段时间后在相同的IP地址和端口之前建立这个连接。端口和ip也相同。那么就会出现包错乱的问题，TCP必须防止来自老的重复的连接再现。所以要存在一个TIME_WAIT的状态。既然TIME_WAIT状态的持续时间是MSL的两倍。这就足以让之前已经错乱的包丢弃。通过这个规则，我们就能保住，每次建立一个新的TCP连接，之前的重复的连接的数据包就会在网络中消逝掉。