因为TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。
连接的建立与终止
TCP的三次握手
1、请求端发送一个SYN段指明客户打算连接的服务器的端口，以及初始序号（ISN，在这个例子中位1415531521）。这个SYN段为报文段1
2、服务器发回包含服务器的初始序号的SYN报文段（报文段2）作为应答，同时，将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认，一个SYN将占用一个序号
3、客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认（报文段3）
image.png
发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）
当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号，ISN随时间而变化，因此每个连接都将具有不同的ISN。
RFC 793指出 ISN可看作是一个32比特的计数器，每4ms加1，这样选序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作错误的解释。
image.png
连接终止协议
终止一个连接需要经过4次握手
由TCP的半关闭（half-close）造成的。以为一个TCP连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。
这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接，当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。
收到一个FIN只意味着在这一方向上没有数据流动，一个TCP连接在收到一个FIN后扔能发送数据。
正常关闭的流程：
image.png
首先进行关闭的一方（即发送第一个FIN）将执行主动关闭，而另一方（收到这个FIN）执行被动关闭，通常一方完成主动关闭而另一方完成被动关闭。
下图是一个终止一个连接的典型握手顺序
image.png
连接通常是由客户端发起的，这样第一个SYN从客户传到服务器，每一端都能主动关闭这个连接（即首先发送FIN）。然而，一般由客户端决定何时终止连接，因为客户进程通常由用户交互控制，用户会键入诸如“quit”一样的命令来终止进程。
连接建立的超时
1、服务器主机没有处于正常状态。
大多数伯克利系统建立一个新连接的最长时间限制为75秒。
最大报文长度MSS
MSS 表示TCP传往另一端的最大块数据的长度。
当一个连接建立时，连接的双方都要通告各自的MSS。
我们已经见过的MSS都是1024，这导致IP数据报通常是40字节长：20字节的TCP首部和20字节的IP首部
MSS并不是任何条件下都可协商，当建立一个连接时，每一方都有用于通告它期望接收的MSS选项（MSS选项只能出现在SYN报文段中）。如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节（这个默认值允许20字节IP首部和20字节的TCP首部以适合576字节IP数据报）。
image.png
如果目的IP地址为“非本地的（nonlocal）”（不是一个网段的）MSS通常的默认值为536。
大多数TCP实现版都提供了一个配置选项，让系统管理员说明不同的子网是属于本地还是非本地。这个选项的设置将确定MSS可以选择尽可能的大（达到外出接口的MTU长度）或是默认值536。
MSS让主机限制另一端发送数据报的长度，加上主机也能控制它发送数据报的长度，这将使较小MTU连接到一个网络上的主机避免分段。
TCP的半关闭
TCP提供了连接的一端在结束它的发送后还能接受来自另一端数据的能力，这就是所谓的TCP 的半关闭。
为了使用这个特性，编程接口必须为应用程序提供一种方式来说明“我已经完成了数据传送，因此发送一个文件结束（FIN）给另一端，但我还想接收另一端发来的数据，直到它给我发来文件结束（FIN）”
image.png
TCP的状态变迁图
image.png
image.png
两个导致进入ESTABLISHED状态的变迁对应打开一个连接，而两个导致从ESTABLISHED状态离开的变迁对应关闭一个连接。
ESTABLISHED状态是连接双方能够进行双向数据传递的状态。
image.png
image.png
2MSL等待状态
TIME_WAIT状态也称为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。
这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。
RFC 793指出MSL为2分钟，实现中的常用值是30秒，1分钟，或2分钟。
对于一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
目前大多数TCP实现（如伯克利版）强加了更加严格的限制，在2MSL等待期间，插口中使用的本地端口在默认情况下不能再被使用。
在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该插口对（socket pair）定义的连接在这段时间内不能被再用，因此当要建立一个有效的连接时，来自该连接的一个较早替身（incarnation）的迟到报文段作为新连接的一部分不可能不被曲解（一个连接由一个插口对来定义，一个连接的新的实例（instance）称为该连接的替身）。
服务器通常执行被动关闭，不会进入TIME_WAIT状态，这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。对客户虽然没什么，但是对于服务器来说，如果我们终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个熟知端口赋值给它的端点，因为那个端口是处于2MSL连接的一部分。在重新启动服务器程序前，它需要在1 ~ 4分钟。
TCP在重启动后的MSL秒内不能建立任何连接，这就称为平静时间（quiet time）
FIN_WAIT_2状态
image.png
复位报文段
TCP首部中RST比特是用于“复位”的。
无论何时一个报文段发往基准的连接（referenced connection）出现错误，TCP都会发出一个复位报文段（基准连接指目的IP地址和目的端口号以及源IP和源端口号指明的连接）。
到不存在的端口的连接请求
产生复位的一种情况是当连接请求到达时，目的端口没有进程正在听，对于UDP的话，会产生一个ICMP端口不可达的消息，而TCP则使用复位。
异常终止一个连接
终止一个连接的正常方式是一方发送FIN，有时这也称为有序释放（orderly release），因为在所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失，但也有可能发送一个复位报文段而不是FIN来中途释放一个连接。有时称这为异常释放（abortive release）
异常终止一个连接对应用程序来说有两个优点：
1、丢弃任何待发数据并立即发送复位报文段
2、RST的接收方会区分另一端执行的是异常关闭还是正常关闭。应用程序使用的API必须提供产生异常关闭而不是正常关闭的手段。
检测半打开链接
如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的TCP连接成为半打开（Half-Open）的
只要不打算在半打开连接上传输数据，扔处于连接状态的一方就不会检测另一方已经出现异常。
1、任何一端的主机异常都可能导致发生这种情况
2、当客户主机突然掉电而不是正常的结束客户应用程序后再关机（可能发生在使用PC机作Telnet的客户主机上）
同时打开
image.png
TCP对于同时打开，它仅建立一条连接而不是两条连接
同时打开情况的状态变迁图：
image.png
两端几乎在同时发送SYN，并进入SYN_SENT状态，当每一端收到SYN时，状态变为SYN_RCVD，同时它们都再发SYN并对收到的SYN进行确认，当双方都收到SYN及相应的ACK时，状态都变迁为ESTABLISHED。
一个同时打开的连接需要交换4个报文段，比正常的三次握手多一个。
相对应的也有同时关闭。
image.png
TCP选项
image.png
image.png
TCP服务器
当一个服务器进程接受一来自客户进程的服务请求时是如何处理端口的？如果多个连接请求几乎同时到达会发生什么情况？
比如，我们看一个Telnet，首先处于LISTEN状态，等待连接请求的到达，之后主机启动一个Telnet客户程序来连接这个Telnet服务器，会发现状态变成了ESTABLISHED状态，但是处于LISTEN状态的服务器进程仍然存在，这个服务器进程是当前Telnet服务器用于接收其他的连接请求，当传入的连接请求到达并被接收时，系统内核中的TCP模块就创建一个处于ESTABLISHED状态的进程，另外处于ESTABLISHED状态的连接的端口不会变化也是23，与处与LISTEN状态的进程相同。
我们再去主机启动另一个Telnet客户进程，并仍与这个Telnet服务器进行连接，那么现在有两条从相同主机到相同服务器的处于ESTABLISHED的连接，它们的本地端口号均为23，由于它们的远端端口号不同，这不会造成冲突，因为每个Telnet客户进程要是用一个外设端口，并且这个外设端口会选择为主机当前未曾使用的端口，因此它们的端口号肯定不同。
呼入连接请求队列
一个并发服务器调用一个新的进程来处理每个客户请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的连接请求，这正是使用并发服务器的根本原因，但仍有可能出现当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求，当服务器正处于忙时，TCP是如何处理这些呼入的连接请求？
image.png
image.png
image.png
网友评论