TCP/IP协议栈 总结（一）

TCP 提供一种面向链接的，可靠的字节流服务。面向链接意味着两个使用TCP的应用（通常一个客户端，一个服务器）在彼此交换数据前必须先建立一个TCP链接。这一过程与打电话很相似，先拨号振铃，等待对方摘机说“喂”，然后才说明是谁。

TCP通过下列方式来提供可靠性

1.应用数据被分割成TCP认为最适合发送的数据块

2.当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

3.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒

4.TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）

5.既然TCP报文段作为I P数据报来传输，而I P数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层

6.既然I P数据报会发生重复， TCP的接收端必须丢弃重复的数据

7.TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出

TCP头

TCP数据被封装在一个IP数据报中，如下图

TCP首部的数据格式。如果不计任选字段，它通常是20个字节。

四元组，唯一确定一条TCP链接

每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上I P首部中的源端I P地址和目的端I P地址唯一确定一个TCP连接。

序号

序号用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32 bit的无符号数，序号到达23 2－1后又从0开始。

全双工

TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号

流量控制

T C P可以表述为一个没有选择确认或否认的滑动窗口协议。我们说T C P缺少选择确认是因为T C P首部中的确认序号表示发方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。例如，如果1～1 0 2 4字节已经成功收到，下一报文段中包含序号从2 0 4 9～3 0 7 2的字节，收端并不能确认这个新的报文段。它所能做的就是发回一个确认序号为1 0 2 5的A C K。它也无法对一个报文段进行否认。例如，如果收到包含1 0 2 5～2 0 4 8字节的报文段，但它的检验和错， T C P接收端所能做的就是发回一个确认序号为1 0 2 5的A C K。

TCP链接与终止

 

链接的建立-三次握手

发送第一个S Y N的一端将执行主动打开（ active open）。接收这个S Y N并发回下一个S Y N的另一端执行被动打开（ passive open）（在1 8 . 8节我们将介绍双方如何都执行主动打开）。当一端为建立连接而发送它的S Y N时，它为连接选择一个初始序号。I S N随时间而变化，因此每个连接都将具有不同的I S N。RFC 793 [Postel 1981c]指出I S N可看作是一个3 2比特的计数器，每4 m s加1。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作错误的解释。

1) 请求端（通常称为客户）发送一个S Y N段指明客户打算连接的服务器的端口，以及初始序号（I S N，在这个例子中为1 4 1 5 5 3 1 5 2 1）。这个S Y N段为报文段1。
2) 服务器发回包含服务器的初始序号的S Y N报文段（报文段2）作为应答。同时，将确认序号设置为客户的I S N加1以对客户的S Y N报文段进行确认。一个S Y N将占用一个序号。
3) 客户必须将确认序号设置为服务器的I S N加1以对服务器的S Y N报文段进行确认（报文段3）。
         这三个报文段完成连接的建立。这个过程也称为三次握手（ three-way handshake）。

链接的断开-四次挥手

建立一个连接需要三次握手，而终止一个连接要经过4次握手。这由T C P的半关闭（h a l f -c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个F I N来终止这个方向连接。当一端收到一个F I N，它必须通知应用层另一端几经终止了那个方向的数据传送。发送F I N通常是应用层进行关闭的结果。
收到一个F I N只意味着在这一方向上没有数据流动。一个T C P连接在收到一个F I N后仍能发送数据。而这对利用半关闭的应用来说是可能的，尽管在实际应用中只有很少的T C P应用程序这样做

TCP的半关闭

T C P提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是所谓下载的半关闭。正如我们早些时候提到的只有很少的应用程序使用它。为了使用这个特性，编程接口必须为应用程序提供一种方式来说明“我已经完成了数据传送，因此发送一个文件结束（ F I N）给另一端，但我还想接收另一端发来的数据，直到它给我发来文件结束（F I N）”。
如果应用程序不调用c l o s e而调用s h u t d o w n，且第2个参数值为1，则插口的A P I支持半关闭。然而，大多数的应用程序通过调用close终止两个方向的连接。

TCP状态迁移图

        在这个图中要注意的第一点是一个状态变迁的子集是“典型的”。我们用粗的实线箭头表示正常的客户端状态变迁，用粗的虚线箭头表示正常的服务器状态变迁。第二点是两个导致进入ESTABLISHED状态的变迁对应打开一个连接，而两个导致从ESTABLISHED状态离开的变迁对应关闭一个连接。ESTABLISHED状态是连接双方能够进行双向数据传递的状态。将图中左下角4个状态放在一个虚线框内，并标为“主动关闭”。其他两个状态（CLOSEWAIT和LASTACK）也用虚线框住，并标为“被动关闭”。在这个图中1 1 个状态的名称（CLOSED, LISTEN, SYN_SENT等）是有意与netstat命令显示的状态名称一致。netstat对状态的命名几乎与在RFC 793 中的最初描述一致。CLOSED状态不是一个真正的状态，而是这个状态图的假想起点和终点。从LISTEN到SYNSENT的变迁是正确的，但伯克利版的TCP软件并不支持它。只有当SYNRCVD状态是从LISTEN状态（正常情况）进入，而不是从SYNSENT状态（同时打开）进入时，从SYNRCVD回到LISTEN的状态变迁才是有效的。这意味着如果我们执行被动关闭（进入LISTEN），收到一个SYN，发送一个带ACK的SYN（进入SYNRCVD），然后收到一个RST，而不是一个ACK，便又回到LISTEN状态并等待另一个连接请求的到来。

TIME_WAIT状态

T I M E WA I T状态也称为2 M S L等待状态。每个具体T C P实现必须选择一个报文段最大生存时间M S L（Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为T C P报文段以I P数据报在网络内传输，而I P数据报则有限制其生存时间的T T L字段。RFC 793 [Postel 1981c] 指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟，或2分钟。

对一个具体实现所给定的M S L值，处理的原则是：当T C P执行一个主动关闭，并发回最后一个A C K，该连接必须在T I M E WA I T状态停留的时间为2倍的M S L。这样可让T C P再次发送最后的A C K以防这个A C K丢失（另一端超时并重发最后的F I N）。这种2 M S L等待的另一个结果是这个T C P连接在2 M S L等待期间，定义这个连接的插口（客户的I P地址和端口号，服务器的I P地址和端口号）不能再被使用。这个连接只能在2 M S L结束后才能再被使用。遗憾的是，大多数T C P实现（如伯克利版）强加了更为严格的限制。在2 M S L等待期间，插口中使用的本地端口在默认情况下不能再被使用。我们将在下面看到这个限制的例子。某些实现和A P I提供了一种避开这个限制的方法。使用插口A P I时，可说明其中的S O R E U S E A D D R选项。它将让调用者对处于2 M S L等待的本地端口进行赋值，但我们将看到TCP原则上仍将避免使用仍处于2MSL连接中的端口。在连接处于2 M S L等待时，任何迟到的报文段将被丢弃。因为处于2 M S L等待的、由该插口对(socket pair)定义的连接在这段时间内不能被再用，因此当要建立一个有效的连接时，来自该连接的一个较早替身（ i n c a r n a t i o n）的迟到报文段作为新连接的一部分不可能不被曲解（一个连接由一个插口对来定义。一个连接的新的实例（ i n s t a n c e）称为该连接的替身）。我们说图1 8 - 1 3中客户执行主动关闭并进入T I M E WA I T是正常的。服务器通常执行被动关闭，不会进入T I M E WA I T状态。这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题，因为客户使用本地端口，而并不关心这个端口号是什么。然而，对于服务器，情况就有所不同，因为服务器使用熟知端口。如果我们终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个熟知端口赋值给它的端点，因为那个端口是处于2 M S L连接的一部分。在重新启动服务器程序前，它需要在1 ~ 4分钟。

TCP定时器

TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对任何实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。我们已经看到过两个超时和重传的例子：

TCP管理4个不同的定时器。
1) 重传定时器使用于当希望收到另一端的确认。。
2) 坚持( per s i s t )定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。第2 2章将讨论这个问题。
3) 保活( k e e p a l i v e )定时器可检测到一个空闲连接的另一端何时崩溃或重启。。
4) 2MSL定时器测量一个连接处于T I M E WA I T状态的时间。

重传定时器

检查连续重传之间不同的时间差，它们取整后分别为1、3、6、1 2、2 4、4 8和多个6 4秒。在本章的后面，我们将看到当第一次发送后所设置的超时时间实际上为1 . 5秒（它在首次发送后的1 . 0 1 3 6秒而不是精确的1 . 5秒后），此后该时间在每次重传时增加1倍并直至6 4秒。这个倍乘关系被称为“指数退避(exponential backoff )。

往返时间测量

T C P超时与重传中最重要的部分就是对一个给定连接的往返时间（ RT T）的测量。由于路由器和网络流量均会变化，因此我们认为这个时间可能经常会发生变化， T C P应该跟踪这些变化并相应地改变其超时时间。首先T C P必须测量在发送一个带有特别序号的字节和接收到包含该字节的确认之间的RT T。在上一章中，我们曾提到在数据报文段和A C K之间通常并没有一一对应的关系。

这意味着发送方可以测量到的一个RT T，是在发送报文段4（第1 ~ 1 0 2 4字节）和接收报文段7（对1 ~ 1 0 2 4字节的A C K）之间的时间，用M表示所测量到的RT T。最初的T C P规范使T C P使用低通过滤器来更新一个被平滑的RT T估计器（记为O）。R← R+ ( 1- )M这里的是一个推荐值为0 . 9的平滑因子。每次进行新测量的时候，这个被平滑的RT T将得到更新。每个新估计的9 0％来自前一个估计，而1 0 %则取自新的测量

TCP坚持定时器

我们已经看到T C P通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。当发送方接收到报文段9时，它打开被报文段8关闭的窗口并立即开始发送数据。T C P必须能够处理打开此窗口的A C K（报文段9）丢失的情况。A C K的传输并不可靠，也就是说， T C P不对A C K报文段进行确认， T C P只确认那些包含有数据的A C K报文段。如果一个确认丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器(persist timer)来周期性地向接收方查询，以便发现窗口是否已增。这些从发送方发出的报文段称为窗口探查( w i n d o wp r o b e )。