计算机网络5-运输层
概述
网络层指把分组发送到目标主机，但真正通信的并不是主机而是主机中的进程。传输层提供了进程之间的逻辑通信，传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输实体之间有一条端到端的逻辑通信信道。
传输层的两个重要协议为
用户数据报协议 UDP (User Datagram Protocol)
传输控制协议 TCP (Transmission Control Protocol)
特性 | UDP | TCP |
连接 | 无连接 | 面向连接 |
可靠性 | 不可靠，不保证交付 | 可靠，保证交付 |
顺序 | 不保证顺序 | 保证顺序 |
速度 | 快，开销小 | 慢，开销大 |
流量控制 | 无 | 滑动窗口 |
拥塞控制 | 无 | 有（慢启动等） |
头部大小 | 8字节 | 20+字节 |
握手 | 无 | 三次握手 |
数据边界 | 保留（数据报） | 不保留（字节流） |
重传 | 无 | 自动重传 |
典型应用 | DNS、视频流、VoIP | HTTP、FTP、邮件 |
协议端口号
在运输层使用协议端口号 (protocol port number)，或通常简称为端口 (port)。把端口设为通信的抽象终点。
端口用16 位端口号进行标志，允许有 65,535 个不同的端口号
两大类、三种类型的端口
常用的熟知端口
可靠传输的工作原理
停止等待协议
每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
并且为每一个已发送的分组设置超时计时器，在到期前收到确认则撤销超时计时器，继续发送下一个分组，否则认为分组错误或丢失，重发该分组。
如果迟到则B收到重复信息丢弃，并重传确认分组，A 会收到重复的确认。对重复的确认的处理：丢弃。
优点：简单。缺点：信道利用率太低。
提高传输效率：流水线传输：在收到确认之前，发送方连续发出多个分组。
连续 ARQ 协议和滑动窗口协议采用流水线传输方式。
连续ARQ协议
发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可被连续发送出去，而不需要等待对方的确认。
发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
累积确认：接收方对按序到达的最后一个分组发送确认，表示：到这个分组为止的所有分组都已正确收到了。
用户数据报协议UDP
UDP 只在 IP 的数据报服务之上增加了一些功能：复用和分用差错检测
复用：将 UDP 用户数据报组装成不同的 IP 数据报，发送到互联网。
分用：根据 UDP 用户数据报首部中的目的端口号，将数据报分别传送到相应的端口，以便应用进程到端口读取数据。
UDP是面向报文的，对应用层传下来的协议，照样发送，对IP层交上来的用户数据报，去除首部后原样交付。
UDP的首部格式
如果接收方UDP发现收到的报文中的目的端口号不正确，就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方。
UDP 的检验和是把首部和数据部分一起都检验
传输控制协议TCP
TCP 是面向连接的运输层协议。
面向流
面向字节流：(流指的是流入或流出进程的字节序列)虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
TCP 不关心应用进程一次把多长的报文发送到 TCP 缓存。TCP 根据对方给出的窗口值和当前网络拥塞程度来决定一个报文段应包含多少个字节，形成 TCP 报文段
TCP的连接
套接字 socket = (IP地址 : 端口号)
端的两个端点（即两个套接字）所确定：
TCP 连接 ::= {socket1, socket2} = {(IP1: port1)，(IP2: port2)}
TCP首部格式
序号 ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
紧急 URG：控制位。当 URG = 1 时，表明紧急指针字段有效，告诉系统此报文段中有紧急数据，应尽快传送 (相当于高优先级的数据)。
确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
推送 PSH (PuSH) ：控制位。接收 TCP 收到 PSH = 1 的报文段后，就尽快（即“推送”向前）交付接收应用进程，而不再等到整个缓存都填满后再交付。
复位 RST (ReSeT) ：控制位。当 RST=1 时，表明 TCP 连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
检验和：占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
在计算检验和时，临时把 12 字节的“伪首部”和 TCP 报文段连接在一起。伪首部仅仅是为了计算检验和
紧急指针：占 2 字节。在 URG = 1时，指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据），指出了紧急数据的末尾在报文段中的位置。
选项：长度可变，最长可达 40 字节。
最大报文段长度 MSS
窗口扩大：（TCP 窗口字段长度= 16 位，最大窗口大小 = 64 K 字节。）
窗口扩大选项：占 3 字节，其中一个字节表示移位值 S。新的窗口值位数从 16 增大到 (16 + S)，相当于把窗口值向左移动 S 位。移位值允许使用的最大值是 14，窗口最大值增大到 2(16 + 14) – 1 = 230 – 1。窗口扩大选项可以在双方初始建立 TCP 连接时进行协商。
时间戳：占 10 字节。最主要的 2 个字段：时间戳值字段（4字节）和时间戳回送回答字段（4字节）。
填充：使整个 TCP 首部长度是 4 字节的整数倍。
TCP滑动窗口
窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。
发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。
发送缓存与发送窗口
发送方的应用进程把字节流写入 TCP 发送缓存。暂时存放：
(1) 发送应用程序传送给发送方 TCP 准备发送的数据；
(2) TCP 已发送出但尚未收到确认的数据
发送窗口通常只是发送缓存的一部分
接收缓存与接收窗口
接收方的应用进程从 TCP 接收缓存中读取尚未被读取的字节。暂时存放：
(1) 按序到达的、但尚未被接收应用程序读取的数据；
(2) 未按序到达的数据。
注意点：
发送窗口是根据接收窗口设置的，但在同一时刻，发送窗口并不总是和接收窗口一样大（因为有一定的时间滞后）。
TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
TCP 要求接收方必须有累积确认的功能，以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，捎带确认实际上并不经常发生。
TCP可靠传输
TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT，加权平均往返时间 RTTs 计算如下：
其中，0 ≤ a ＜ 1，RTTs 随着 a 的增加更容易受到 RTT 的影响。RFC 6298 推荐的a 值为 1/8，即 0.125
超时时间 RTO 应该略大于 RTTs，TCP 使用的超时时间计算如下：
其中 RTTd 为偏差的加权平均值。
Karn 算法：报文段每重传一次，就把 RTO 增大一些，当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
选择确认SACK：只传送缺少的数据而不重传已经正确到达接收方的数据，如果要使用选择确认，在建立 TCP 连接时，要在 TCP 首部的选项中加上允许 SACK 选项，且双方必须事先商定好。
TCP流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
持续计时器：时间到期发送零窗口探测报文段，对方在确认这个探测报文段时给出当前窗口值。若为零，接收方重新设置持续计时器，若不是零，死锁僵局打破。
TCP拥塞控制
如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。
发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的。
注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
为了便于讨论，做如下假设：
接收方有足够大的接收缓存，因此不会发生流量控制；
虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。
慢开始与拥塞避免
发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...
注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。
发送窗口的上限值 = Min [rwnd, cwnd]
快重传和快恢复
在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
在发送方，如果收到三个重复确认（3-ACK），那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。
在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。
慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。
15. (单选题, 2分) 主机甲和主机乙新建一个TCP连接，甲的初始慢开始阈值为32KB，甲向乙始终以MSS=1KB大小的报文段发送数据，并一直有数据发送；乙为该连接分配16KB接收缓存，并对每个数据段进行确认。忽略报文段的传输时延。若乙收到的数据全部存入缓存，不被取走，则甲从连接建立成功时刻起，未出现发送超时或连续收到三个重复确认的情况下，经过4个RTT后，甲的发送窗口大小是（ 1KB）。
RTT1：cwnd ：2 KB，rwnd：15KB,发送窗口：min(2,15)=2
RTT2: cwnd :4KB,rwnd:13KB,发送窗口：min(4,13)=4
RTT3: cwnd :8KB,rwnd:9KB,发送窗口：min(8,9)=8
RTT4: cwnd :16KB,rwnd:1KB,发送窗口：min(16,1)=1
TCP运输连接管理
TCP的三次握手
假设 A 为客户端，B 为服务器端。
首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。
A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。
B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。
A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。
B 收到 A 的确认后，连接建立。
三次握手的原因
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。
TCP的四次挥手
以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。
A 发送连接释放报文，FIN=1。
B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
当 B 不再需要连接时，发送连接释放报文，FIN=1。
A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
B 收到 A 的确认后释放连接。
四次挥手的原因
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。
TIME_WAIT
客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：
确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。