5.1运输层概述
运输层直接为应用进程间的逻辑通信提供服务
- 计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
- 但实际上进行通信的是位于通信两端主机的进程
- 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。
5.2 运输层端口号、复用和分用的概念
端口号
因为不同操作系统的进程标识符(PID)是不一样的，所以为了使不同操作系统之间的进程进行通信，就必须采用统一的方法对TCP/IP的应用进程进行标识。
TCP/IP体系的运输层使用端口号区分应用层的不同应用进程。
端口号使用16比特表示，取值范围0~65535：
端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，
不同计算机中的相同端口号是没有联系的。
发送方的复用和接收方的分用
举例：运输层端口号的作用
当我们在PC端浏览器输入域名之后，会发生什么？
首先PC端中的DNS客户端会向DNS服务器发送一个DNS查询请求报文用来查询域名www.porttest.com对应的IP地址是什么。DNS查询请求报文会使用UDP协议封装成UDP数据报：
53是我们常用的熟知的UDP端口号
之后会将UDP数据报封装在IP数据报中，通过以太网发送到DNS服务器。DNS服务器收到之后会从，识别端口号为53，将该数据报交给DNS服务器中的DNS服务端，服务端对该条数据报进行解析，识别出查询请求，然后按照要求查询该域名对应的IP地址，之后生成DNS响应报文，使用UDP协议封装成UDP数据报，接着将UDP数据报封装在IP数据包中，通过以太网发送到用户PC
用户PC将该数据报放到DNS客户端进程，解析内容之后，知道了该域名对应的IP地址。
然后http客户端使用对web服务器发送http请求报文，该报文的内容是请求首页内容。该报文通过运输层中的TCP协议封装成TCP报文段，接着TCP报文段封装到IP数据报中，通过以太网发送到Web服务器。
Web解析之后，识别到端口号为80，将该报文发送到http服务器端，服务器端进行解析，响应生成http响应报文，然后将该报文中封装到TCP数据报中，接着将TCP数据报封装到IP数据报中，然后通过以太网发回用户PC。用户PC接收到之后将TCP数据报交给http客户端，然后对其进行解析，生成了主页内容。
5.3 UDP和TCP的对比
UDP是无连接的，TCP是面向连接的
UPD支持多播、单薄、广播，TCP只支持单播
UDP是面向应用报文的，TCP是面向字节流的
UDP实现不可靠传输，TCP实现可靠传输
数据报首部对比
5.4 TCP的流量控制
- 一般来说，我们总是希望数据传输得更快一些。
- 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
- 所谓流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。
- 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
举例
练习：
5.5 TCP的拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞(congestion)。
在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。
慢开始
拥塞避免
当检测到到达慢开始门限16之后，不再进行指数级增长
这个时候，一定会出现部分报文段丢失的现象，重传计时器超时，判断网络很可能出现了拥塞，进行以下工作：
将ssthresh值更新为发生拥塞时cwnd值的一半；将cwnd值减少为1，并重新开始执行慢开始算法。
当达到新的门限值时，又继续执行拥塞避免算法。
慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复(TCP Reno版本)。
快重传
快恢复
总结：
例题：
5.6 TCP超时重传时间的选择
超时重传时间(RTO)的选择标准
如果超时重传时间远小于往返时间
会使网络负荷增大如果超时重传时间远大于往返时间:
会降低传输效率
所以超时重传时间应该略大于往返时间
但是在互联网中，往返时间是不确定的，所以超时重传时间的确认就是一个很复杂的事情
超时重传时间(RTO)的计算方法
往返时间RTT的测量方法
但是往返时间RTT的测量是比较复杂的
针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs,进而超时重传时间RTO也不会重新计算。
这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kan算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
因此，要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。
举例：
5.7 可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输
如何描述发送窗口的状态？
例题：
5.8 TCP的传输连接管理
5.8.1 TCP的连接建立
TCP的连接建立要解决以下三个问题：
- 使TCP双方能够确知对方的存在：
- 使TCP双方能够协商一些参数（如最大窗口 值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
- 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。
TCP 使用"三报文握手"建立连接
不采取两次握手是为了防止已失数的连接请求报文段突然叉传送到了TCP服务器。
例题：
5.8.2 TCP的运输连接管理一TCP的连接释放
TCP通过“四报文挥手”来释放连接
为什么需要时间等待？
保活计时器的作用：
5.9 TCP报文段的首部格式
源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
保留：占6比特，保留为今后使用，但目前应置为0。
校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
终止标志位FIN:用来释放TCP连接。
复位标志位RST:用来复位TCP连接。当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，
而不必等到接收缓存都填满后再向上交付。
填充：由于选项的长度可变，因此使用填充来确保报文段首部能被4整除
(因为数据偏移字段，也就是首部长度字段，是以4字节为单位的)
