运输层服务
- 运输层协议为运行在不同主机上的应用进程之间提供逻辑通信。
- 运输层协议是在端系统中实现。
- 网络层提供了主机之间的逻辑通信，运输层则是为运行在不同主机上的进程提供逻辑通信。
- UDP和TCP最基本的责任是，将两个端系统间IP的交付服务护展为运行在端系统上的两个进程之间的交付服务。将主机间交付扩展到进程间交付被称为运输层的多路复用(transport- layer multiplexing)与多路分解( demultiplexing)。
多路复用与多路分解
- 在接收端，运输层检查字段，标识出接收套接字，进而将报文段定向到该套接字。将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。
- 在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息(这将在以后用于分解)从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用(muliplexing)。
- UDP套接字是由一个二元组来全面标识的，该二元组包含一个目的IP地址和一个目的端口号。
- TCP套接字是由一个四元组来标识（源IP地址、源端口号、源目的P地址、目的端口号）
UDP
UDP优点
- 无需连接建立，因此UDP不会引入建立连接时延
- 无连接状态
- 分组首部开销小，TCP20字节首部开销，UDP仅有8字节
-
关于何时、发送什么数据的应用层控制更加精细
应用层协议.png
UDP报文结构
UDP报文段结构.png
- 通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程(即执行分解功能)。
- 长度字段指示了在UDP报文段中的字节数(首部加数据)。
- 接收方使用检验和检查报文段是否出现差错。
UDP检验和
发送方：
- 将数据的每两个字节当作一个16位的整数，可分成若干整数；
- 将所有16 位的整数求和
- 对得到的和逐位取反，作为检查和，放在报文段首部，一起发送
接收方： - 对接收到的信息 (包括检查和)求和
全“1”：数据无错；
其中有“0”：数据出错
TCP
- TCP连接是点对点
-
三次握手:客户首先发送一个特殊的TCP报文段，服务器用另一个特殊的TCP报文段来响应，最后，客户再用第三个特殊报文段作为响应。前两个报文段不承载“有效载荷”，也就是不包含应用层数据;而第三个报文段可以承载有效载荷。
TCP发送和接收缓存.png
TCP报文结构
TCP报文结构.png
- 接收窗口字段——用于流量控制，指示接收方愿意接收的字节数量。
- 4比特的首部长度字段( header length field)， 该字段指示了以32比特的字为单位的TCP首部长度。
- 可选与变长的选项字段( options field)， 该字段用于发送方与接收方协商最大报文段长度(MSS) 时，或在高速网络环境下用作窗口调节因子时使用。
- 一个报文段的序号( sequence number for a segment)是该报文段首字节的字节流编号。
- A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。
估计往返时间
报文段的样本RTT (表示为SampleRTT) 就是从某报文段被发出(即交给IP)到对该报文段的确认被收到之间的时间量。
- EstimatedRTT=0. 875EstimatedRTT+O. 125SampleRTT
- RTT的偏差DevRTT=(1-β)DevRTT +β| SampleRTT - EstimatedRTT| (β=0.25)
- 则重传超时间隔TimeoutInterval = EstimatedRTT +4.*DevRTT
TCP连接管理
TCP连接.png
- 第一步:客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。该报文段中不包含应用层数据。但是在报文段的首部中的一个标志位(即SYN比特)被置为1。因此，这个特殊报文段被称为SYN报文段。另外，客户会随机地选择一个初始序号( client_ isn)， 并将此编号放置于该起始的TCP SYN报文段的序号字段中。该报文段会被封装在一个IP数据报中，并发送给服务器。
- 第二步:一旦包含TCP SYN报文段的IP数据报到达服务器主机，服务器会从该数据报中提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向该客户TCP发送允许连接的报文段。这个允许连接的报文段也不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。首先，SYN比特被置为1。其次，该TCP报文段首部的确认号字段被置为client . isn + 1。最后，服务器选择自己的初始序号(server jisn)， 并将其放置到TCP报文段首部的序号字段中。
-
第三步:在收到SYNACK报文段后，客户也要给该连接分配缓存和变量。客户主机则向服务器发送另外一个报文段;这最后一个报文段对服务器的允许连接的报文段进行了确认(该客户通过将值server_ isn+1放置到TCP报文段首部的确认字段中来完成此项工作)。因为连接已经建立了，所以该SYN比特被置为0。该三次握手的第三个阶段可以在报文段负载中携带客户到服务器的数据。
TCP关闭.png
假设某客户打算关闭连接，客户应用进程发出一个关闭连接命令。这会引起客户TCP向服务器进程发送一个特殊的TCP报文段。这个特殊的报文段让其首部中的一个标志位即FIN比特被设置为1。当服务器接收到该报文段后，就向发送方回送一个确认报文段。然后，服务器发送它自己的终止报文段，其FIN比特被置为1。最后，该客户对这个服务器的终止报文段进行确认。此时，在两台主机上用于该连接的所有资源都被释放了。
经典TCP状态.png
流量控制
- TCP为它的应用程序提供了流量控制服务(flow-controlservice)以消除发送方使接收方缓存溢出的可能性。流量控制因此是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。
- TCP通过让发送方维护一个称为接收窗口( receive window)的变量来提供流量控制。通俗地说，接收窗口用于给发送方一个指示——该接收方还有多少可用的缓存空间。
拥塞控制
拥塞网络的代价
- 当分组的到达速率接近链路容量时，分组经历巨大的分组时延
- 发送方必须执行重传以补偿因为缓存溢出而丢弃的分组。
- 发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
- 即当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。
拥塞控制的方法 - 端到端拥塞控制。在端到端拥塞控制方法中，网络层没有为运输层拥塞控制提供显式支持。即使网络中存在拥塞，端系统也必须通过对网络行为的观察(如分组丢失与时延)来推断之。TCP报文段的丢失(通过超时或了次冗余确认而得知)被认为是网络拥塞的一个迹象，TCP会相应地减小其窗口长度。
- 网络辅助的拥塞控制。在网络辅助的拥塞控制中，路由器向发送方提供关于网络中拥塞状态的显式反馈信息。
