运输层位于应用层和网络层之间，是分层的网络体系结构的重要部分，该层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。
一、概述和运输层服务
运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。在发送端，运输层将从发送应用程序进程接受到的报文转换成运输层报文段，运输层将这些报文传递给网络层，网络层将其封装为网络层分组并向目的地发送。
1、运输层和网络层的关系
运输层协议只工作在端系统中，在端系统中，运输层协议将来自应用进程的报文移动到网络边缘，反过来也是一样，但对有关这些报文在网络核心如何移动不作任何规定。运输协议能够提供的某些服务常常受制于底层网络层协议的服务模型，如果网络层协议不能为主机间发送的传输层报文段提供延迟或带宽保证，那么传输层协议就不能为进程间发送的应用消息提供延迟或带宽保证。然而，即使底层网络协议不能在网络层提供相应的服务，传输层协议也可以提供某些服务。
2、因特网运输层协议
因特网网络层协议名字为IP，即网络协议。IP为主机之间提供了逻辑通信，IP的服务模型是尽力而为交付服务，它会尽最大努力在通信的主机间交付报文，但它不做任何保证，如不确保报文段的交付，不保证报文段的按需交付，不保证报文段中数据的完整性，因而IP为称为不可靠服务。
UDP和TCP最基本的责任是，将端系统间IP的交付服务扩展为运行在端系统上的两个进程间的交付服务。将主机间交付扩展到进程间交付被称为运输层的多路复用与多路分解。进程到进程间的数据交付和差错检查是两种最低限度的运输层服务，也是UDP提供的仅有的两种服务。TCP则提供了几种附加服务，首先他提供可靠数据传输，通过使用流量控制、序号、确认和定时器，TCP将两个端系统间的不可靠的IP服务转换成了一种进程间的可靠数据传输服务，此外TCP还提供拥塞控制，来防止任何一条TCP连接用过多流量来淹没通信主机之间的链路和交换设备
二、多路复用与多路分解
当计算机中的运输层从底层的网络接收数据时，它需要将所接收到的数据定向到不同的进程，每个进程有一个或多个套接字，它相当于从网络向进程传递数据和从进程向网络传递数据的门户。将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。
套接字有唯一的标识符，而每个报文段有特殊字段来指示该报文段要交付到的套接字，多路复用可以借助这两个特点来展开工作。上述的特殊字段是源端口号字段和目的端口号字段。端口号是一个16比特的数，其大小在0~65535之间，0~1023范围的端口号称为周知端口号，是受限制的，它们会保留给HTTP的80和FTP的21之类的周知应用协议使用。从上面不难推断出多路分解的执行流程，它可以借助报文段中的目的端口号将其定向到对应的套接字，然后报文中的数据通过套接字进入其所连接的进程。
1、无连接的多路复用与多路分解
一个UDP套接字是有一个二元组（源端口号和目的端口号）全面标识的，该二元组包含一个目的IP地址和一个目的端口号，因此会出现多个不同报文段通过相同的目的套接字被定位到相同的目的进程。源端口的用途则是可以作为“返回地址“的一部分
2、面向连接的多路复用与多路分解
TCP套接字是由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）来标识的。与UDP不同的是，两个具有不同源IP地址或源端口号的到达TCP报文将被定向到两个不同的套接字，除非TCP报文携带了初始创建连接的请求。
3、Web服务器与TCP
连接套接字与进程之间并非总是有着一一对应的关系，事实上，当今的高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程，因此在任意的给定时间内都可能有许多连接套接字连接到相同的进程。
三、无连接运输：UDP
除了复用/分解功能及少量的差错检测外，它几乎没有对IP增加别的东西。UDP有如下优点：
- 关于发送什么数据以及何时发送的应用层控制更加精细；TCP的拥塞控制机制会遏制运输层TCP的发送方；
- 无需建立连接；因此不会引入建立连接的时延；这也是DNS运行在UDP而不是TCP的原因；
- 无连接状态；TCP需要在端系统中维护连接状态，包括接受和发送缓存，拥塞控制机制参数以及序号及确认号的参数；
- 分组首部开销小；UDP仅有8字节的开销，TCP报文段则有20字节的首部开销；
1、UDP报文结构字段
UDP报文结构如上图所示，应用层数据会占用UDP报文段的数据字段，如对于DNS来说，数据字段要么包含一个查询报文要么包含一个响应报文。长度字段指示了在UDP报文段中的字节数（首部+数据）；接收方使用校验和来检查该报文段中是否出现了差错，计算校验和时，除了UDP报文段以外还包括了IP首部的一些字段
2、UDP校验和
UDP校验和提供了差错检查功能，也就是用来确认UDP报文段从源到达目的地移动时，其中的比特是否发生了变化。发送方的UDP报文对报文段中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都会被回卷。反码运算就是将所有的0换成1，所有的1换成0
许多链路层协议也提供了错差检测，但并不能保证所有链路都进行提供了差错检测，即如果端到端数据传输服务要提供错查检测，UDP就必须在端到端基础上在运输层提供错查检测，这就是系统设计上的端到端原则。
四、可靠数据传输原理
下图为可靠数据传输服务模型框架，在该框架中为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输，而实现这种服务的抽象是可靠数据传输协议的职责。由于可靠数据传输协议的下层协议也许是不可靠的，所以这是一项困难的任务。在本节中，我们仅考虑单项数据传输的情况，暂不考虑双向数据传输（全双工数据传输）。
1、构造可靠数据传输协议
1.1、经完全可靠信道的可靠数据传输：rdt1.0
首先考虑最简单的情况，即底层信道是完全可靠的，我们称该协议为rdt1.0，该协议本身是简单的，这里我们定义rdt1.0发送方和接收方的有限状态机（FSM），FSM会定义发送方和接收方的操作。图中的发送方和接收方的FSM每个都只有一个状态，箭头描述了从一个状态变迁到另一个状态，引起变迁的事件显示在横线上方，事件发生所采取的动作显示在横线的下方。FSM的初始状态使用虚线表示。
rdt的发送端通过rdt_send(data)事件接受来自较高层的数据，产生一个包含该数据的分组，并将分组发送到信道中，rdt_send(data)实际上是由较高层应用过程调用产生的。在接收端，rdt通过rdt_rcv(packet)事件从底层信道接受一个分组，从分组取出数据，并将数据上传给较高层，dt_rcv(packet)事件实际上是由较低层协议的过程调用产生的。
1.2、经具有比特差错信道的可靠数据传输：rdt2.0
①底层信道更为实际的模型是分组中的比特可能受损的模型，在分组的传输、传播或缓存过程中，这种比特差错通常出现在网络的物理部件中。在通常情况下，报文接受者在听到理解并记下每句话时可能会说OK，在听到含糊不清的话时，他可能要求你重复那句容易误解的话，这种口述报文协议使用了肯定确认与否定确认。在计算机网络环境中，基于这样重传机制的可靠数据传输协议称为自动重传请求协议（Automatic Repeat reQuest，ARQ）。ARQ协议中需要另外三种协议来处理存在比特差错的情况：
- 差错检测：首先需要一种机制使得接收方检测何时出现了比特差错，这些技术要求有额外的比特从发送方发送到接收方，这些毕业被汇集在rdt2.0数据分组的分组检验和字段中；
- 接收方反馈：发送发需要了解接收方情况的唯一途径就是让接收方提供明确的反馈信息给发送方，类似于口述回答的肯定回答（ACK）和否定回答（NAK），rdt2.0协议将从接受方向发送方回送ACK和NAK分组，理论上可以使用一个比特长即0表示NAK，1表示ACK
- 重传：接收方收到有差错的分组时，发送方将重传该分组文；
②rdt2.0的发送端有两种状态：等待上层调用或等待ACK或NAK。需要注意的是，当发送方处于等待ACK或NAK状态时，它不能从上层获得更多的数据。因此，发送方将不会发送一块新数据，除非发送方确信接受方已经正确接受当前分组，由于这种行为，rdt2.0这样的协议被称为停等协议。rdt2.0接收方的FSM仍然只有单一状态，分组到达时，要么回答ACK要么回答NAK，者取决于收到的分组是否受损。
③看起来rdt2.0可以运行了，但是它存在一个致命的缺陷，就是没有考虑到ACK或NAK分组受损的可能性。其难点在于如果一个ACK或NAK分组受损，发送方无法知道接收方是否正确接受了上一块发送的数据，这里考虑三种可能性：
- 考虑在口述报文的情况下，由于不理解接收方的回复，说话者可能会问“你说什么”，情况是接收者不明白说话者是没接受到自己的回答还是不明白；
- 第二种情况是增加足够的校验和比特位，使发送方不仅可以检测差错，还可以恢复差错，对于产生差错但不丢失分组的信道，可以直接解决问题；
- 第三种情况是发送方收到含糊不清的ACK或NAK分组时，只需重传当前分组即可，然而这种方法在发送方到接收方的信道中引入了冗余分组，冗余分组的困难在于接受方不知道它上次发送的ACK或NAK分组是否被发送方正确地收到，因此它无法知道接受到的分组是新的还是一次重传
解决新问题的简单方法是在数据分组中添加一个新的字段，让发送方对其数据分组编号，即将发送数据分组的序号放在该字段。接收方只需要检查序号及可以确定收到的分组是否一次重传
1.3、经具有比特差错的丢包信道的可靠数据传输：rdt3.0
假定除了比特受损外，底层信道还会丢包，则协议现在需要处理两个问题，怎样检测丢包以及发生丢包后该做些什么？有很多方法用于解决丢包问题，这里我们让发送方负责检测和恢复丢包工作。假定发送方传输一个分组，该分组或接收方对该分组的ACK发生了丢失，这样发送方是接受不到响应的，这种情况下发送方会等待一段时间并重新发送分组。通常是发送方和接收方之间的一个往返时延加上接收方处理一个分组所需要的时间。
为了实现基于时间的重传机制，需要一个倒计数定时器，在一个给定的时间量过期后，可中断发送方。因此发送方需要做到：①每次发送一个分组时启动一个定时器；②响应定时器中断；③终止定时器。综上，因为分组序号会在0和1之间交替，所以rdt3.0也被称为比特交替协议
2、流水线可靠数据传输协议
rdt3.0是一个功能正确的协议，但在今天的高速网络中，其性能因其停等协议会有一定的影响。我们定义发送方的利用率U=(L/R)/(RTT+L/R)，其中R为发送速率，L为分组长，计算发现在停等协议的情况下，效率是非常低的。
如果不以停等方式运行，允许发送方发送多个分组而无需等待，其利用率将大大提高。因为许多从发送方向接受方输送的分组可以看作是填充到一条流水线中，故这种技术被称为流水线。它会对可靠数据传输协议带来如下影响：
- 必须增加序号范围，因为每个输送中的分组必须有一个唯一的序号；
- 协议的发送方和接收方两端也许不得不缓存多个分组，发送方最低限度应当能缓冲那些已发送但没有确认的分组，接收方需要缓存那些以正确接受的分组；
- 所需序号的范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。
解决流水线的差错恢复有两种基本方法：回退N步（Go-Back-N，GBN）和选择重传（Selective Repeat，SR）
3、回退N步
在回退N步协议中，允许发送方发送多个分组而不需要等待确认，但它也受限于在流水线中未确认分组数不能超过某个最大允许数N。这里我们定义基序号base为最早未确认分组的序号，下一个序号nextSeqnum定义为最小未使用序号，则序号分为可以划分为：[0,base-1]已发送并确认，[base,nextSeqnum-1]对应已发送未确认，[nextSeqnum,base+N-1]对应即将被发送的分组，大于等于base+N的序号不可用直到被确认的分组已经得到确认。随着协议的运行，GBN协议的序号空间向前滑动，因此N被称为窗口长度，GBN协议被称为滑动窗口协议。
GBN的发送方必须响应三种类型的事件：
- 上层的调用：当上层调用时，发送方首先检查发送窗口是否已满，如果窗口未满则产生一个分组并将其发送，如果窗口已满发送方只需将数据返回给上层并指示窗口已满。在实际中，发送方会缓存这些数据，或者使用同步机制允许上层在窗口不满时再次调用。
- 收到一个ACK，在GBN协议中，对序号为n的分组确认采取累积确认的方式，表明接收方已经接收到序号为n的且以前包括n在内的所有分组。
- 超时事件，如果出现超时，发送方将重传所有已发送但还未被确认过的分组。
4、选择重传
选择重传协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传，按需重传要求接收方逐个确认正确接受的分组。SR接受方将确认一个正确接收的分组而不管其是否按序，失序的分组将被缓存直到所有丢失分组皆被收到为止。
当我们面对有限序号范围的实现时，发送方和接收方窗口间缺乏同步会产生严重的后果，比如无法确认超出窗口长度的序号是重传还是初次传输。所以窗口长度比序号空间小1时协议无法工作。此外考虑分组重新排序的情况，信道可被看成基本上是在缓存分组，并在将来任意时刻自然地释放这些分组，由于序号可以被重新使用，所以要十分小心。实际中采用的方法是确保一个序号不被重新使用，直到发送方确信任何先前发送序号为x的分组都不在网络中为止。
五、面向连接的运输：TCP
1、TCP连接
TCP被称为是面向连接的，这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先相互握手，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。TCP协议只在端系统中运行，而不在中间的网格元素中运行，所以中间的网格元素不会维持TCP的连接状态，事实上，中间路由器对TCP连接完全视而不见，它们看到的是数据报而不是连接。
TCP连接提供的是全双工服务：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可以从进程B流向进程A的同时，也可以从进程A流向进程B。TCP的连接是点对点的，即在单个发送方与单个接收方之间连接。
客户进程通过套接字传递数据流，一旦建立起连接，TCP将这些数据引导到该连接的发送缓存里，发送缓存是发起三次握手期间设置的缓存之一，TCP会在它方便的时候以报文段的形式将数据传递到网络层。TCP可以从缓存中取出并放入报文段中的数据数量受限于最大报文长度（MSS）。MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度（即最大传输单元MTU）来设置，设置该MSS要保证一个TCP报文段加上TCP/IP首部长度（通常40个字节）将适合单个链路层帧。以太网和PPP链路层协议都具有1500字节的MTU，因此MSS的典型值为1460字节。注意MSS是指在报文段里应用层数据的最大长度，并不包括首部TCP报文段。
TCP为每块客户数据配上一个TCP首部，从而形成多个TCP报文段。这些报文段被下传给网络层，网络层将其分别封装在网络层IP数据报中，然后这些IP数据报被发送到网络中。
2、TCP报文段结构
TCP报文段由首部字段和一个数据字段组成，数据字段包含一块应用数据。MSS限制了报文段数据字段的最大长度，当TCP发送一个大文件时，TCP通常将该文件划分为长度为MSS的若干块。
TCP报文段的首部包括源端口号，目的端口号，用于多路复用/分解来自或送到上层应用的数据。TCP首部也包括检验和字段，以及如下字段：
- 32比特的序号字段(sequence number field)和32比特的确认号字段(acknowledgment number field)；
- 16比特的接受窗口字段(ewceive window field)，用于流量控制，指示接收方愿意接受的字节数量；
- 4比特的首部长度字段(header length field)，该字段指示了以32比特的字为单位的TCP首部长度；由于TCP选项字段，TCP的首部长度是可变的；
- 可选与变长的选项字段(options field)，用于用于发送方或接收方协商最大报文段长度，或在高速网络环境下用作窗口调节因子；
- 6比特的标志字段(flag field)，ACK比特用于指示确认字段中的值是有效的，RST、SYN与FIN比特用于连接建立和拆除，还有其他如PSH、URG和紧急数据指针比特；
2.1、序号和确认号
TCP报文段中首部中两个最重要的字段是序号字段与确认号字段，这两个字段是TCP可靠传输服务的关键部分。一个报文段的序号是该报文段首字节的字节流编号。由于TCP是全双工的，因此主机A在向主机B发送数据时，也许也接受来自主机B的数据，从主机B到达的每个报文段中都有一个序号用于从B流向A的数据，主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号
举个例子，假设主机A收到来自主机B的一个包含字节0到535的报文段和另一个包含字节900到1,000的段。由于某些原因，主机A还没有收到字节536到899的报文段。在这个例子中，主机A仍在等待字节536(及以后的字节)，以便重新构建主机B的数据流。因此，A到B的下一个报文段将在确认号字段中包含536。由于TCP只对流中第一个缺失的字节以内的字节进行确认，所以TCP被称为提供是累积确认
最后一个例子也带来了一个重要而微妙的问题。主机A在收到第二段(字节536至899)之前收到了第三段(字节900至1000)。因此，第三段失序到达。当主机在TCP连接中接收到失序的段时该怎么办？开发人员有两种选择：(1)接收方立即丢弃失报文段(2)接收方保留失序的字节，并等待缺失的字节来填补空缺。后一种选择对网络带宽而言更有效率，也是实践中采取的方法。
2.2、学习案例-略
3、往返时间的估计与超时
TCP采用超时/重传机制来处理报文段的丢失问题，其实现最明显的问题是超时间隔长度的设置。
3.1、估计往返时间
大多数TCP的实现仅在某个时刻做一次SamoleRTT测量，而不是每个发送的报文段测量一个SampleRTT，也就是说在任意时刻，仅为一个已发送的但目前尚未被确认的报文段估算SampleRTT，从而产生一个接近每个RTT的新SampleRTT值。另外，TCP决不为已被重传的报文段计算SampleRTT，它仅为传输一次的报文段测量SampleRTT。
由于路由器的拥塞和端系统负载的变化，报文段的SampleRTT值会随之变动，TCP维持一个SampleRTT均值（称为EstimatedRTT），一旦获取一个新SampleRTT，TCP就会根据下列公式来更新EstimatedRTT：EstimatedRTT=(1-α)*EstimatedRTT+α*SampleRTT，α的推荐值是0.125
除了估算RTT外，测量RTT的变化也是有价值的，RTT偏差DevRTT的公式为DevRTT = (1 –β)*DevRTT + β•|SampleRTT–EstimatedRTT|，β的推荐值为0.125
3.2、设置和管理重传超时间隔
超时间隔不应该比EstimatedRTT大太多，因此要求将超时间隔设为EstimatedRTT加上一定的余量，当SampleRTT值波动大时，余量应该大些；当波动较小时，余量小些，综上：TimeoutInterval=EstimatedRTT+4*DevRTT，推荐的初始TimeoutInterval值为1秒，当出现超时后，TimeoutInterval值将加倍，以免即将被确认的后继报文段过早出现超时，一旦收到报文段并更新EstimetedRTT，将使用上述公式再次计算TimeoutInterval
4、可靠数据传输
TCP在IP不可靠的尽力而为为服务创建了一种可靠数据传输服务。TCP的可靠数据传输服务确保了一个进程从其接受缓存中读出的数据流是无损坏、无间隙、非冗余和按序的数据流，即该字节流与连接的另一方端系统发出的字节流是完全相同的。
考虑TCP发送方高度简化的描述，TCP发送方有3个与发送和重传有关的主要事件：从上层应用程序接受数据，定时器超时和收到ACK。
4.1、一些有趣的情况
考虑第一种场景，主机A向主机B发送一个报文段，假设这个报文段的序号为92，包含8比特的数据。发送完这个报文段后，主机A等待来自主机B编号为100的回复报文段。虽然在B处收到了来自A的报文段，但从B到A的确认报文丢失了。在这种情况下，就会发生超时事件，主机A重新发送相同的报文段。当主机B收到重传的报文段时，它将从序列号中观察到该段包含已经收到的数据。因此，主机B中的TCP将丢弃重传报文段中的字节。
考虑第二种场景，主机A连续发送了两个报文段。第一个报文段的序列号为92，数据为8个字节，第二个报文段的序列号为100，数据为20个字节。假设这两个报文段都完好无损地到达B处，B为每个报文段分别发送一个确认。第一个确认报文的确认号是100; 第二个确认报文的确认号是120。 假设现在两个确认报文段都没有在超时之前到达主机A。当超时事件发生时，主机A重新发送序列号为92的第一段，并重新启动定时器。只要第二段的ACK在新的超时之前到达，第二段将不会被重新发送。
考虑第三种场景，假设主机A发送了两个报文段，第一段的确认报文在网络中丢失了，但就在超时事件之前，主机A收到了一个确认号为120的报文确认，因此主机A知道主机B已经通过字节119收到了所有的东西，所以主机A不重新发送这两个段中的任何一个。
4.2、超时间隔加倍
每当超时事件发生时，TCP重传具有最小序号的还未被确认的报文段，并且每次TCP重传时都会将下一次的超时间隔设置为先前值的两倍，而不是从EstimatedRTT和DevRTT推算出值。然而，每当定时器在另外两个事件：收到上层应用的数据和收到ACK中的任意一个启动时，TimeoutInterval由最近的EstimatedRTT和DevRTT的值得到。
4.3、快速重传
超时触发重传存在的问题之一是超时周期可能比较长。 当一个段丢失时，这个长的超时周期迫使发送方延迟重发丢失的数据包，从而增加了端到端延迟。这种情况下。发送方可以在超时事件发生之前，通过冗余ACK来检测数据包丢失的情况。冗余ACK就是再次确认某个报文段的ACK，发送方先前已经受到过该报文段的确认。
如果TCP发送方对同一个数据收到了三次重复的ACK，它就会认为这表明被确认过三次的报文段之后的报文段已经丢失。一旦收到三个冗余的ACK，TCP就会执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
4.4、回退N步还是选择重传
TCP的是累积确认的，正确接收但是失序的报文段并是不会被接收方逐个确认的。因此TCP发送方只需要维护一个已发送但未被确认的字节的最小序列号和下一个要发送的字节的序列号。从这个意义上说，TCP看起来很像GBN风格的协议。但是TCP和Go-Back-N之间有一些明显的区别。GBN会重传确认异常后的同组报文段而TCP最多重传一个。
会TCP提出的一种修改意见是选择重传，允许TCP接收器选择性地确认无序段，而不是仅仅累积确认最后一个正确接收的有序段。当与选择性重传相结合时，TCP看起来很像我们的通用SR协议。因此，TCP的错误恢复机制可能最好被归类为GBN和SR协议的混合体。
5、流量控制
TCP连接的两边的主机都为连接预留了一个接收缓冲区。当TCP连接接收到正确且按顺序的字节时，它将数据放入接收缓冲区。相关的应用程序进程将从这个缓冲区中读取数据。如果应用程序读取数据的速度很慢，那么发送者很容易因为发送过快的数据而溢出连接的接收缓冲区，TCP为其应用程序提供了流量控制服务，以消除发送者使接收方溢出缓冲区的可能性。因此，流量控制是一种速度匹配服务--将发送方发送的速度与接收方应用的读取速度进行匹配。
TCP通过让发送方维护一个称为接受窗口的变量来提供流量控制，接收窗口用于给发送方一个指示，该接收方还有多少可用的缓存空间。考虑一种情况，主机B接受主机A发送的数据，且恰好该数据传送完成后主机B的缓存空间被占满，在主机B清空完缓存后，主机A会不知道主机B已经有了新的缓存空间。为了解决这个问题，TCP规范中要求：当主机B的接受窗口为0时，主机A继续发送只有一个字节数据的报文段，这些报文段会被接收方确认，最终缓存将开始清空，并且确认报文中将包含一个非0的接受窗口值。
6、TCP连接管理
1、三次握手：
- 第一步：客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文，报文段的首部一个标志位（SYN比特）被置为1，因此该报文被称为SYN报文段。此外客户会随机的选择一个初始序号（client_isn），并将该初始序号放置在SYN报文段的序号字段中，该报文段最终会被封装在一个IP数据报中，并发送给服务器
- 第二步：包含SYN报文的IP数据到达服务器后，服务器会从该数据报中提取出SYN报文段，为该TCP连接分配TCP缓存和变量，并向该客户TCP发送允许连接的报文段。这个允许连接的报文段首部中包含3个重要的信息：①SYN比特会被置为1，②首部的确认号字段会被置为clinet_isn+1，③最后服务器选择自己的初始序号(server_isn)并将其放置在报文段首部的序号字段中。这个被允许连接的报文段被称为SYNACK报文段
- 第三步：在收到SUNACK报文段后，客户也要给该连接分配缓存和变量，并发送另外一个报文段，该报文段对服务器允许连接的报文段进行了确认（通过将server_isn+1放置到TCP报文段首部的确认字段中来完成此项工作）。连接建立后，SYN比特被置为0，且这一步可以携带客户到服务器的数据
2、4次挥手：参与一条TCP连接的两个进程中的任意一个都能终止该连接
- 如客户端发起关闭连接请求，该TCP报文首部的一个标志位即FIN比特被置为1；
- 服务器接受到该报文后，会向发送方回送一个确认段报文；
- 随后，服务器发送它自己的终止报文段，FIN比特被置为1；
- 客户对服务器的终止报文段进行确认，完成后两端用于该连接的所有资源都会被释放；
3、相关的连接状态
4、考虑连接异常的情况，主机会发送一个特殊的重置报文段，该TCP报文段将RST标志位置为1，以提示发送方无匹配的报文套接字；针对UDP连接不匹配的情况，主机会返回一个ICMP数据报
六、拥塞控制原理
1、拥塞原因及代价
1、考虑最简单的拥塞情况：两台发送主机A和B，连接两端间的路由器（无穷大缓存）和一段容量为R的共享式输出链路，当两台主机的发送速率超过R/2时，路由器中的平均排队分组就会无限延长，源与目的地之间的平均时延也会变为无穷大。即当分组的到达速率接近链路容量时，分组经历巨大的排队时延。
2、两个发送方和一台拥有优先缓存的路由器：当分组到达一个已满的缓存时会被丢弃，而如果包含有运输层报文段的分组在路由器中被丢弃，那么它会被发送方重传。在发送方确认了一个分组已经丢失时才重传的情况下，发送方必须执行重传以弥补因为缓存而丢弃的分组。而当发送方提前发生超时并重传在队列中已经被推迟但还未被丢失的分组情况下（接收方已经接受到了该分组的初始版本所以重传分组会被丢弃），发送方子遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本
3、4个发送方和具有有限缓存的多台路由器及多跳路径：4台主机发送分组，每台都通过交叠的两跳路径传输，考虑主机A-主机C以及主机D-主机B的连接共享路由器R1，并与B-D连接共享路由器R2，当A-C连接与B-D连接在路由器R2上为有限缓存空间进行竞争时，且当B-D的连接通过越来越大时，A-C的连接会越来越拥堵，直到吞吐量趋向于0。即当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费了。
2、拥塞控制方法
在最宽泛的级别上，可以根据网络层是否为运输层拥塞控制提供了显式帮助，来区分拥塞控制的方法：
-
端到端拥塞控制：在端到端的拥塞控制方法中，网络层没有为运输层拥塞控制提供显式支持。
-
网络辅助的拥塞控制：在网络辅助的拥塞控制中，路由器向发送方提供关于网络中拥塞状态的显式反馈信息。
对于网络辅助的拥塞控制，拥塞信息从网络反馈到发送方通常有两种方式：①直接反馈信息由网络路由器发送给对方；②路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生。
七、TCP拥塞控制
TCP必须使用端到端拥塞控制而不是网络辅助的拥塞控制，因为IP层不向端系统提供显式的网络拥塞反馈。TCP所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其向连接发送流量的速率。TCP发送方如果感知没有拥塞，那么TCP发送方就会增加其发送速率；如果发送方认为路径上存在拥塞，那么发送方就会降低其发送速率。但是这种方法会带来三个问题。第一，TCP发送方如何限制其发送的速率？其次，TCP发送方如何感知到在本身和目的地之间存在拥塞？第三，发送方应该用什么算法来改变其发送速率？
1、运行在发送方的TCP拥塞控制机制跟踪一个额外的变量，即拥塞窗口（cwnd），它对一个TCP发送方能向网络中发送流量的速率进行了限制。考虑TCP接受的缓存足够大，即忽略接受窗口的限制，当出现过度的用拥塞时，路径上的一台或多台路由器的缓存会溢出，引起一个数据包被丢失，丢弃的数据报会引起发送方的丢包事件（超时或收到3个冗余的ACK），发送方就会认为在发送方到接收方的路径上出现 了拥塞的指示。
2、当网络中没有出现拥塞时，TCP接收端会将收到对以前未确认报文段的确认，TCP将这些确认的到达作为一切正常的指示，并使用确认来增加窗口（传输速率）的长度。TCP使用确认来增大它的拥塞窗口长度，因而TCP是自计时的。TCP是如何确定它应当发送的速率呢？TCP使用下列指导性原则：
- 一个丢失的报文段意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率；
- 一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此当对先前未确认报文段的确认到达时，能够增加发送方的速率；
- 带宽探测；为探测拥塞控制开始出现的速率，TCP发送方增加它的传输速率，从该速率探测直到开始出现拥塞；
3、TCP拥塞控制算法：①慢启动；②拥塞避免；③快速恢复。慢启动和拥塞避免是TCP的强制部分，快速恢复是推荐部分，对于TCP发送方并非是必须的；
1、慢启动
当一条TCP连接开始时，cwnd的值通常初始置为一个MSS的较小值，因而初始发送速率大约为MSS/RTT。TCP发送方希望迅速找到可用带宽的数量，因此在慢启动状态，cwmd的值以一个MSS开始并且每当传输的报文段首次被确认就增加一个MSS，随着发送报文段指数级的增长，MSS也会不断的翻番。因此TCP发送速率起始慢，但在慢启动阶段后呈指数增长。增长如何结束？①如果存在一个由超时指示的丢包事件，TCP发送方会将cwnd设置为1并重新开始慢启动过程，并将慢启动阈值ssthresh设置为cwnd/2；②当cwnd的值等于ssthresh（原先的cwnd/2）时，慢启动结束并且转移到拥塞避免模式；③当检测到3个冗余的ACK，TCP执行一种快速重传并进入快速恢复状态；
2、拥塞避免
一旦进入拥塞避免的状态，cwnd的值大约是上次遇到用拥塞时值的一半，因此TCP采用了一种较为保守的方法，每个RTT只将cwnd的值增加一个MSS，通用的方法就是对于TCP发送方如论何时到达一个新的确认，就将cwnd增加一个MSS字节。何时结束线性的增长呢？与慢启动的情况一样，cwnd的值被设置为一个MSS，当丢包事件出现时，ssthresh的值被更新为cwnd值的一半，并进入快速恢复状态
3、快速恢复
在快速恢复中，对于引起TCP进入快速恢复状态的缺失报文段，每收到一个重复的ACK，cwnd的值增加一个MSS，最终当对丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免状态。