物理层、数据链路层、网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信 运输层直接为应用进程间的逻辑通信提供服务，使用不同的端口号来区分不同的应用进程

运输层端口号、复用与分用的概念

运行在计算机上的进程使用进程标识符PID来标志。 因特网上的计算机并不是使用统一的操作系统，不同的操作系统(windows，Linux，Mac OS)又使用不同格式的进程标识符。 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识，

TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。 端口号使用16比特表示，取值范围0~65535:

• 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如:FTP’使用21/20，HTTP使用80，DNS使用53.
• 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如:Microsoft RDP 微软远程桌面使用的端口是3389。
• 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。

发送方的复用和接收方的分用

发送方的某些应用进程所发送的不同应用报文在运输层使用UDP协议进行封装，这称为UDP复用，使用TCP协议封装称为TCP复用，运输层使用端口号来区分不同的应用进程 不管是使用UDP协议封装成的用户数据报还是使用TCP协议封装成的报文段在网络层都需要使用IP协议封装成IP数据报，这称为IP复用，IP数据报首部中协议字段的值用来表明IP数据报的数据载荷部分封装的是何种协议数据单元，取值为6表示封装的是TCP报文段，取值为17表示封装的是用户数据报 接收方接收到IP数据报后进行IP分用，若IP数据报中协议字段的值为17，则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP，若协议部分为6，则把数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。运输层对UDP用户数据报进行UDP分用，对TCP报文段进行TCP分用也就是根据端口号将它们交付给上层相应的应用进程，

TCP/IP体系的应用层常用协议和所使用的运输层熟知端口号： UDP：

1. RIP 520
2. DNS 53
3. TFTP 69
4. SNMP 161
5. DHCP 67/68 TCP：
6. SMTP 25
7. FTP 21/20
8. BGP 179
9. HTTP 80
10. HTTPS 443 不管运输层使用的何种协议在网络层都使用IP协议

示例：

用户PC、DNS服务器、Web服务器通过交换机进行互联，它们处于同一个以太网中，Web服务器有一个域名，DNS服务器中记录有该域名对应的IP地址 用户pc通过浏览器访问Web服务器的内容时，先在浏览器的地址栏中输入Web服务器的域名，用户pc中的DNS客户端进行会发送一个dns查询请求报文，内容为查询该域名对应的IP地址，dns请求报文使用运输层的udp协议封装成udp用户数据报，其首部中需要填写源端口和目的端口，在短暂端口号49151~65535中挑选一个未被占用的用来表示dns客户端进程，目的端口的值设置为53，这是dns服务器端进程所使用的熟知端口号，之后将udp用户数据报封装在ip数据报中，通过以太网发送给dns服务器，dns服务器收到ip数据报后从中解封出udp用户数据报，udp首部中的目的端口为53表明应将udp用户数据报的数据载荷部分也就是dns查询请求报文交付给本服务器中的dns服务器端进程，dns服务器端进程解析dns查询请求报文的内容，然后按其要求查找对应的ip地址。之后会给用户pc发送dns响应报文，其内容为该域名对应的ip地址。dns相应报文使用运输层的udp协议封装成udp用户数据报，其首部的源端口字段的值为数值端口号53，表明这是dns服务器端进程所发送的udp用户数据报。目的端口号的值为请求报文的源端口号，这是之前用户pc中发送dns查村请求报文的dns客户端进程所使用的短暂端口号。之后将udp用户数据报封装在ip数据报中通过以太网发送给用户pc，用户pc收到该数据报后从中解封出udp用户数据报，根据udp首部中的目的端口号知道应将该udp用户数据报的数据载荷部分也就是dns响应报文交付给用户pc中的dns客户端进程，dns客户端进程解析dns响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的ip地址。 现在用户pc中的http客户端进程可以向Web服务器发送http请求报文了。例如：请求首页内容。http请求报文使用运输层的tcp协议封装成tcp报文段，源端口从短暂端口中挑选一个未被占用的，用来表示http客户端进程。目的端口号设置为80，这是http服务器端进程所使用的熟知端口号。之后将tcp报文断封装在ip数据报中通过以太网发送给Web服务器。Web服务器收到该数据报后从中解封出tcp报文段，tcp首部中的目的端口号为80，这表明应该将该tcp报文段的数据载荷部分也就是http请求报文交付给本服务器 的http服务器端进程。此进程解析http请求报文的内容，然后按其要求查找内容，之后会给用户pc发送http响应报文，其内容为所请求的内容。http响应报文使用运输层的tcp协议封装成tcp报文段，其源端口号和目的端口号和请求报文中的相反，之后将tcp报文段封装成ip数据报通过以太网发送给用户pc，用户pc解析后根据目的端口得知交付给哪个进程，然后该进程解析其中的内容在浏览器中显示出来。

UDP和TCP

UDP和TCP是TCP/IP体系中重要的协议

UDP

User Datagram Protocol 使用upd协议的通信双方可以随时发送数据 udp是无连接的

udp可以向某个多播组发送多播（一对多） 向某台主机发送单播（一对一） 向所有主机发送广播（一对全）

对应用报文的处理： 发送方的应用进程将应用报文交付给运输层的udp，udp直接给应用层报文添加一个udp首部，使之称为udp用户数据报，然后进行发送。接收方收到udp用户数据报后，去掉udp首部，将应用层报文交付给应用进程， 也就是说udp对应用层交下来的报文既不拆分也不合并，而是保留这些报文的边界。 udp是面向应用报文的

udp向上层提供的是无连接不可靠传输服务 对于udp用户数据包出现的误码和丢失等问题，udp并不关心，因此udp适用于ip电话、视频会议等实时应用

由于udp并不提供可靠服务，它仅仅在网际层的基础上添加了区分应用进程的端口，因此它的首部非常简单只有8个字节

TCP

Transmission Control Protocol 使用tcp协议的通信双方在进行数据传输之前必须使用三报文握手来建立tcp连接，tcp连接建立成功后才能进行数据传输，数据传输结束后必须使用四报文挥手来释放tcp连接。 这里的连接是指逻辑连接关系而不是物理连接 tcp是面向连接的

tcp仅支持单播也就是一对一的通信

发送方的tcp将应用进程交下来的数据块仅仅看作是一连串的、无结构的字节流，tcp并不知道这些待传送的字节流的含义，仅将它们编号并存储在自己的发送缓存中，tcp根据发送策略从缓存中提取一定数量的字节，构建tcp报文段并发送，接收方的tcp一方面从所接收到的tcp报文段中取出数据载荷部分并存储在接收缓存中，一方面将接收缓存中的一些字节交付给应用进程。tcp不保证接收方收到的数据块与发送方发送的数据块具有对应大小的关系，例如：发送方应用进程交给发送方tcp10个数据块，但接收方的tcp可能只用了4个数据块就把收到的字节流交付给了上层的应用进程。但接收方接收到的字节流必须和发送方应用进程发出的字节流完全一样。这样也要求接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据 也就是说tcp是面向字节流的 这正是tcp实现可靠传输、流量控制、以及拥塞控制的基础。 基于tcp连接的两端可以同时进行tcp报文段的发送和接收，也就是全双工通信。

尽管网际协议向上层提供的是无连接不可靠的传输服务，但只要运输层使用tcp协议，就可向上层提供面向连接的可靠传输服务。适用于要求可靠传输的应用，如文件传输

tcp首部要比udp首部复杂的多，其最小为20字节，最大为60字节。这是因为tcp要实现可靠传输、流量控制、拥塞控制等服务。

TCP流量控制

如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失 所谓流量控制（flow control）就是让发送方的发送频率不要太快，要让接收方来得及接收 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方地流量控制

举例： 假设两台主机已经建立tcp连接，a给b发送数据，b对a进行流量控制。假设主机a发送的每个tcp数据报文段可携带100字节的数据。 在a和b建立tcp连接时a获得b的接收窗口大小，假设为400。这样a的发送窗口大小也应为400。主机a在未收到b发来的确认时，可将序号落入发送窗口的全部数据发送出去。 a将落在发送窗口中的1~100的数据封装成一个tcp报文段发送出去（seq=1 data），发送窗口还有300字节可以发送，seq是tcp报文段首部的序号字段，取值1表示tcp报文段的数据载荷的第一个字节的序号是1，data表示这是tcp数据报文段。a再将101~200的数据封装成一个tcp报文发送出去（seq=101 data），发送窗口还有200字节可以发送。a再将201~300的数据封装成一个tcp报文段发送出去，但该报文段在传输过程中丢失了。主机b对a发送的201号之前的数据进行累积确认，并在该累积确认中将窗口字段的值调整为300也就是对主机a进行流量控制（发送ACK=1 ack=201 rwnd=300）ACK是tcp报文段首部的标志位，取值1表示这是一个tcp确认报文段，ack是tcp报文段首部中的确认号字段，取值201表示序号201之前的数据已全部接收，rwnd是tcp报文段首部中的窗口字段，取值300表示字节接收窗口的大小为300，a的发送窗口也应根其改为300。a收到确认报文后把发送窗口向后移，并把201之前的数据删除，然后再把发送窗口大小也改为300，其检测到发送窗口内还有301_400和401500的数据可以发送，就把这些数据也发送出去，此时落在发送窗口的所有数据都发送了出去，计时器检测到201_{300的数据没有收到确认信息就超时重传。b收到这些数据后对501之前的数据进行累积确认，并将接收窗口调整为100，这是第二次对a进行流量控制。a收到确认报文后发送窗口再向后移动，并缩小为100，再把确认过的数据删除，然后发送501}600的数据，b收到后对601号之前的数据进行确认并把接收窗口的大小改为0，a收到确认信息后发送窗口往后移删除已确认数据，发送窗口改为0，此时不能发送一般报文段了。

假设b向a发送零窗口的报文段后不久，b的接收缓存又有了一些存储空间，于是b向a发送了接收窗口等于300的报文段。若这个报文段在传输过程中丢失了。a一直等待b发送的非0窗口通知，而b也一直等待a发送的数据。如果不采取措施这种等待形成的死锁会一直持续下去。为了解决这个问题tcp为每个连接设有一个持续计时器。只要tcp连接的一方收到对方的零窗口通知，就启动持续定时器，若持续计时器超时，就发送一个零窗口探测报文段，仅携带一字节的数据。而对方在确认这个探测报文段时，给出自己现在的接收窗口值，如果接收窗口仍然是0，那么收到这个报文段的一方就重新启动持续计时器。如果接收窗口不是0，那么死锁的局面就被打破了。

主机a收到零窗口通知时就启动一个持续计时器，当持续计时器超时，a就立刻发送一个仅携带一字节的零窗口探测报文段。b收到后就对零窗口探测报文进行确认并告知自己的接收窗口（假设此时又为0），a接收到后就又启动一个新的持续计时器，超时后就发送零窗口探测报文，若零窗口探测报文丢失，持续计时器超时再重传一个零窗口探测报文，b收到后对其确认并告知自己的接收窗口假设此时为300，这样就打破了死锁局面‘

TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏这种情况就叫做拥塞（congestion)。 在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。 介绍四种拥塞控制算法：

• 慢开始slow-start
• 拥塞避免congestion avoidance
• 快重传fast retransmit
• 快恢复fast recovery

为方便理解假定以下条件： 数据是单方向传送，而另一个方向只传送确认。 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。 发送方将拥塞窗口作为发送窗口swnd，即swnd=cwnd。 维护一个慢开始门限ssthresh状态变量： 当cwnd<ssthresh时，使用慢开始算法 当cwnd>Ssthresh时，停止使用慢开始算法而改用拥塞避免算法 当cwnd=ssthresh时既可使用慢开始算法，也可以使用拥塞避免算法

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法（TCPTahoe版本）。

假设ssthresh=16，cwnd=1 在执行慢开始算法时，发送方每收到一个对新报文段的确认时，就把拥塞窗口值加1，然后开始下一轮的传输，当拥塞窗口增长到慢开始门限值时，就改为执行拥塞避免算法，拥塞窗口值是几就能发送几个数据报文段 开始时cwnd=1发送方发送0号数据报文段，收到接收方发送对0号的确认时cwnd+1=2，这时发送方发送1_{2号报文段，当收到接收方发送的对1}2号的确认时cwnd+2=4，依次指数增长，当cwnd=ssthresh时（为16），就停止慢开始算法转为cwnd每次+1，也就是发送方发送16个数据报文段，接收到对这16个的确认后cwnd+1=17，下次可以发送17个。假设在某次数据报文段发送时丢失了几个，这时发送方就会对这些丢失的报文段超时重传，发送方依此判断网络可能发送了拥塞。就将ssthresh改为发生拥塞时拥塞窗口的一半（假设发生拥塞时拥塞窗口大小为24，此时慢开始门限的就为12），这样再重现开始慢开始算法

慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；拥塞避免”并非指完全能够避免拥塞，而在拥塞避免阶段将拥塞窗口控制为按线性规律增长，便使网络比较不容易出现拥塞

1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCPReno版本）。有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。这将导致发送方超时重传，并误认为网络发生了拥塞； 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。要求接收方不要等待自己发送数据时才进行销带确认，而是要立即发送确认；即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。

快重传

快恢复 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3。原因：既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

超时重传时间的选择

超时重传时间RTO的值小于往返时间RTT会导致不必要的重传，远大于rtt会使网络的空闲时间增大，降低传输效率，因此rto应略大于rtt 但数据传输时因为路由的不同以及复杂的网络导致每个报文的rtt都不同

不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO 利用每次测量得到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）

$RTO=RTT_{S}+4\times RTT_D$

• 加权平均往返时间$RTT_S$$RTT_{S1}=RTT_1$$新的RTT_S=(1-\alpha)\times旧的RTT_S+a\times新的RTT样本$

0≤α<1 若α很接近于0，则新RTT样本对RTTs的影响不大 若α很接近于1，则新RTT样本对RTTs的影响较大； 已成为建议标准的RFC6298推荐的α值为1/8，即0.125。

• RTT偏差的加权平均$RTT_D$$RTT_{D1}=\frac{RTT_1}{2}$$新的RTT_D=(1-\beta)\times 旧的RTT_D+\beta\times|RTT_S-新的RTT样本|$

0≤β<1 已成为建议标准的RFC6298推荐的β值为1/4，即0.25。

用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。 显然，超时重传时间RTO应略大于加权平均往返时间RTT。

源主机若误将确认当作是对原报文段的确认 所计算出的RTTs和RTO就会偏大，降低了传输效率；

源主机若误将确认当作是对重传报文段的确认 所计算出的RTTs和RTO就会偏小，导致报文段没必要的重传，增大网络负荷；

当发送方出现超时重传，收到确认报文时，无法判断出该确认是对原报文段的确认还是对重传报文段的确认，因此无法准确测量出RTT进而无法正确计算出RTO

针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。 因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为I旧RTO值的2倍。

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输的 连续发送三个同样的确认报文才会重传请求的数据，这样做是考虑到有的分组因为延迟比后面的顺序分组晚到

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。 对于不按序到达的数据应如何处理，TCP并无明确规定。 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。 TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程 TCP要求接收方必须有累积确认和捐带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便销带上。 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC1122]。 捐带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。 TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。

TCP连接的建立

TCP的连接建立要解决以下三个问题：

1. 使TCP双方能够确知对方的存在
2. 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
3. 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

其中一台主机中的某个应用进程主动发起TCP连接建立称为TCP客户 另一台主机中被动等待TCP连接建立的应用进程称为TCP服务器

一开始双方的TCP连接都处于关闭状态，tcp服务器会首先创建传输控制块，用来存储tcp连接中的一些重要信息（如：TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针、当前的发送和接收序号等）之后准备接收tcp客户的连接请求，此时tcp服务器进程就进入监听状态。tcp服务器进程是被动等待来自tcp客户进程的连接请求，而不是主动发起称为被动打开连接 tcp客户也是首先创建tcp控制块，向tcp服务器进程发送tcp连接请求报文段，并进入同步已发送状态，tcp连接请求报文段首部中的同步位SYN设置为1，表明这是一个tcp连接请求报文段，序号字段seq设置一个初始值x，作为tcp客户进程所选择的初始序号（tcp规定syn被设置为1的报文段不携带数据，但要消耗掉一个序号）由于tcp连接建立时由tcp客户主动发起的，称为主动打开连接 tcp服务器进程接收到连接请求报文段后，如果同意建立连接，则向tcp客户进程发送tcp连接请求确认报文段，并进入同步已接收状态，该报文段首部中的同步位syn和确认位ACK都设置为1，表明这时一个tcp连接请求确认报文段，序号段seq设置为y，作为tcp服务器进程所选择的初始序号，确认号字段ack的值被设置成了x+1，这是对tcp客户进程所选择的初始序号的确认。（这个报文段也不能携带数据，同样也需要消耗掉一个序号） tcp客户进程收到tcp连接请求确认报文后， 还要向tcp服务器进程发送一个普通的tcp确认报文段，并进入连接已建立状态。该报文段首部的确认为ack被设置为1，表明这是一个普通的tcp确认报文段（普通的tcp确认报文段可以携带数据，但如果不携带数据，则不消耗序号），序号字段seq被设置为x+1，这是因为tcp客户进程发送的第一个tcp报文段的序号为x，确认号字段ack被设置为y+1，这是对tcp服务器进程所选择的初始序号的确认，tcp服务器进程收到该确认报文段后也进入连接已建立状态。现在双方的连接已经建立，可以进行数据传输了

最后一步的握手不能省略，假设ecp客户发送一个连接请求，但因为某些原因在网络节点长时间滞留了，这会引起超时重传，客户再发送一个连接请求，服务器收到连接请求后，针对该请求进行确认，并进入已建立连接状态（没有同步已接收状态），客户收到确认后也进入连接状态，两者连接后发送数据，发送完成断开连接。断开连接后滞留的连接请求发送到服务器了，服务器再次进入连接已建立状态并发送确认，由于客户进程并未发起新的tcp连接请求，并且处于关闭状态，因此对于该确认不予理睬，但服务器认为新的tcp连接建立好了，并一直等待客户进程发送数据，这将白白浪费tcp服务器进程所在主机的很多资源。

TCP连接释放

假设客户进程通知其主动关闭连接，客户进程会发送tcp连接释放报文段，并进入终止等待1状态，该报文段首部中的终止位fin和确认位ACK都被设为1，表明这是一鞥tcp连接释放报文段，同时也对之前收到的报文段进行确认，序号seq字段的值设置为u=tcp客户进程之前已传送过的、数据的最后一个字节的序号+1，tcp规定终止位fin等于1的报文段即使不携带数据，也要消耗掉一个序号。确认号ack字段的值设置为v=tcp客户进程之前已经收到的、数据的最后一个字节的序号加1，tcp服务器进程收到tcp连接释放报文段后，会发送一个普通的tcp确认报文段并进入关闭等待状态，该报文首部确认位ACK=1表明这是一个普通的tcp确认报文段，序号seq=v它等于tcp服务器进程之前已传送过的数据的最后一个字节的序号+1，这也与之前tcp释放报文段的确认号ack匹配，确认号ack字段的值=u+1，这是对tcp连接释放报文段的确认。tcp服务器进程这时应通知高层应用进程，客户进程要断开与自己的tcp连接，从客户到服务器这个方向的连接就释放了。这时的tcp连接属于半关闭状态，也就是客户没有数据要发送了，但服务器进程如果还有数据要发送客户进程仍要接收（从服务器到客户方向的连接并未关闭）这个状态可能会持续一段时间。 客户进程收到tcp确认报文段后就进入终止等待2状态，等待tcp服务器进程发出的tcp连接释放报文段，若服务进程的应用进程已经没有数据要发送了，应用进程就通知其tcp服务器进程来释放连接，由于tcp连接释放是由tcp客户进程主动发起的，因此tcp服务器进程对tcp连接的释放称为被动关闭连接。服务器进程发送tcp连接释放报文段并进入最后确认状态，该报文段首部中的终止位fin和确认位ACK的值都被设置为1，表明这是一个tcp连接释放报文，同时也对之前收到的报文段进行确认，现在假定序号seq字段的值为w，这时因为在半关闭状态下，tcp服务器进程可能又发送了一条数据。确认号ack字段的值为u+1，这是对之前收到的tcp连接释放报文段的重复确认，客户进程收到连接释放报文后必须针对该报文段发送普通的tcp确认报文段，之后进入时间等待状态，seq为u+1，这时因为之前连接释放报文即使不携带数据也要消耗掉一个符号，确认号ack的值为w+1，这是对所收到的tcp连接释放报文段的确认，服务器进程收到该报文段好就进入关闭状态，而客户进程还要经过2MSL后才能进入关闭状态。 MSL（Maximum Segment Lifetime）意思是最长报文段寿命，RFC793建议为2分钟 也就是说客户进程进入时间等待状态后还要经过四分钟才能进入关闭状态 对于现在的网络MSL取2分钟可能太长，tcp允许不同的实现可格局具体情况使用更小的MSL值

客户进程在发送完最后一个确认报文后为什么不直接进入关闭状态而要进入时间等待状态 若发送完确认报文段后直接进入关闭状态，如果确认报文丢失，服务器收不到确认报文就会超时重传tcp连接关闭报文段，但由于客户进程已经关闭所以对重传的报文不予理睬，这样服务器进程就一直重传连接关闭报文，一直在最后确认状态 而且等待MSL时长可以保证本次连接的所有报文全部消失，不会导致新tcp连接中出现旧的报文段

TCP保活计时器 可以用来发现客户端是否出现故障 TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时） 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

TCP报文段首部格式

• 源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程
• 目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程
• 序号：占32比特，取值范围$[0,2^{32}-1]$，序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号。
• 确认号：占32比特，取值范围$[0,2^{32}-1]$，确认号增加到最后一个后，下一个确认号就又回到0。 指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。 若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。
• 确认标志位ACK：取值为1时确认号字段才有效；取值为0时确认号字段无效。 TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1
• 同步标志位SYN：在TCP连接建立时用来同步序号（在连接请求报文段时置1）
• 终止标志位FIN：月用来释放TCP连接（在连接释放报文段中置1）
• 复位标志位RST：用来复位TCP连接。 当RST=1时，表明TCP连接出现了异常，必须释放连接，多然后再重新建立连接 RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
• 推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程而不必等到接收缓存都填满后再向上交付。
• 紧急标志位URG：取值为1时紧急指针字段有效；取值为0时紧急指针字段无效。
• 紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。 当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。
• 数据偏移：占4比特，并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部长度。 首部固定长度为20字节，因此数据偏移字段的最小值为bin（0101） 首部最大长度为60字节，因此数据偏移字段的最大值为bin（1111）
• 保留：占6比特，保留为今后使用，但目前应置为0。
• 窗口：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。 窗口值作为接收方让发送方设置其发送窗口的依据。 这是以接收方的接收能力来控制发送方的发送能力，和称为流量控制。 发送窗口的大小还取决于拥塞窗口的大小，也就是应该从接收窗口和拥塞窗口中取最小值
• 校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。 在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
• 选项（长度可变）：除了固定部分还有最大40字节的选项部分，增加选项可以增加TCP的功能

1. 最大报文段长度MSS选项：指出TCP报文段数据载荷部分的最大长度
2. 窗口扩大选项：为了扩大窗口（提高吞吐率）
3. 时间戳选项：用来计算往返时间RTT和用于处理序号超范围的情况，又称为防止序号绕回PAWS。
4. 选择确认选项：用来实现选择确认功能

• 填充：由于选项的长度可变，因此使用填充来确保报文段首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）

贡献者

pinkdopeybug

版权所有

版权归属：PinkDopeyBug

许可证：署名 4.0 国际 (CC-BY-4.0)