传输层的基本理论和基本机制：
多路复用/分用
可靠数据传输机制
流量拥塞控制机制
拥塞控制机制
Internet的传输层协议：
UDP：无连接传输服务
不可靠的交付服务，基于“尽力而为”的网络层。（多路分用、多路复用）
TCP：面向连接的传输服务
可靠、按序的交付服务，提供拥塞控制、流量控制、连接建立
UDP和TCP的共同点：都不保证延迟、带宽
3.1传输层服务和协议：
传输层协议(end - end)为运行在不同Host上的进程提供了一种逻辑通信机制
工作方式:
特点:
位于网络层之上
依赖于网络层服务
对网络层服务进行可能的增强
区别:
网络层:提供主机之间的逻辑通信机制
一个主机上可能会有多个应用进程
3.2 复用和分用：
接收端进行多路分用：传输层依据头部信息将收到的segment交给正确的Socket，即不同的进程(接收端有多个应用进程)
发送端进行多路复用：从多个Socket接收数据，为每块数据封装上头部信息，生成Segment，交给网络层(发送端有多个应用进程)
多路分用的工作方式:
数据报(datagram)的组成：源IP地址、目的IP地址、传输层的段(Segment)
段的格式:
主机接收IP数据报，收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向给相应的Socket
无连接的多路分用(UDP)：
数据报中的SP(源端口号)提供了返回地址
疑问：目的IP地址？？？
面向连接的多路分用(TCP)：
多线程Web服务器：
一个进程创建多个线程
3.3无连接传输协议-UDP：
基于Internet IP协议：
复用/分用，有简单的错误校验；
“Best effort”服务，UDP段可能丢失，非按序到达；
发送方与接收方之间不需要连接，每个UDP段的处理独立于其他段
好处:
无需连接->减少延迟(DNS、SNMP)
实现简单->无需维护连接状态
头部开销少
无拥塞控制
应用媒体的特点:容忍丢失、速率敏感
实现可靠数据传输的方法：
在应用层上增加可靠性机制、应用特定的错误回复机制
UDP段的格式:
checksum:UDP校验和
检验方法:
校验和计算的例子：
3.4：可靠数据传输原理（rdt）
（上层应用）
rdt只考虑单向数据传输，但控制信息双向流动，可用状态机(FSM)刻画
rdt1.0：可靠信道上的可靠数据传输
底层信道完全可靠；
发送方和接收方的FSM独立：
停等协议：
rdt2.0：产生位错误的信道->ARQ协议(自动重传请求协议)
1.利用校验和检测位错误
2.恢复：(ACK、NAK接收方反馈控制消息)
确认机制(ACK)：接收方显式地告知发送方已正确接收分组
NAK：接收方显示地告知发送方分组有错误
发送方收到NAK后，重传分组
FSM：
缺陷:
ACK/NAK存在坏掉的可能。
若ACK/NAK坏掉，发送方若简单重传，则会产生重复分组
rdt 2.1:解决重复分组问题
发送方为每个分组增加序列号，接收方丢弃重复分组
发送方FSM：
接收方FSM：
接收方遇到不符合的序列号时，返回ACK->看发送方的FSM
rdt 2.2:无NAK的消息协议
FSM:
接收端的工作过程：
rdt3.0:信道发生错误、丢失分组
发送端FSM:
工作过程：
rdt3.0的性能很差(停等操作)->网络协议限制了物理资源的利用
3.5：滑动窗口协议
利用流水机制提高资源的利用率：
允许发送方在收到ACK之前连续发送多个分组，分组具有更大的序列号范围，发送方、接收方(可能)需要更大的存储空间以缓存分组
实现：滑动窗口协议(GBN、SR)
Go-Back-N协议：
发送方：
FSM:
接收方(无缓存)：
操作过程：
GBN示例(*)：
补充：Ws+1<=序列号总数
缺陷：需要重传重复的分组
Selective Repeat协议：
补充：接收方收到 pkt n，n在[recvbase-N,rcvbase-1]中，需要再发一个ACK的原因：
发送方以收到ACK为标准进行滑动，发送方窗口和接收方窗口的滑动可能不同步，当接收方的窗口滑动得比发送方得窗口快时，若收到pkt n,n in[rcvbase-N,rcvbase-1]时，需要告诉发送方，分组已缓存，已避免发送方认为分组丢失，从而使发送方窗口向前滑动。
SR协议示例(*)：
要求：发送方窗口的尺寸+接收方窗口的尺寸<=序列号的个数
3.6:面向连接传输协议-TCP
TCP的特点:
1.点对点的连接，一个发送方、一个接收方
2.提供可靠的、按序的字节流(在IP层提供的不可靠服务基础上实现可靠数据传输服务)
3.采用流水线机制，包括TCP拥塞控制和流量控制，设置窗口的尺寸
4.发送方和接收方都有缓存
5.全双工：同一连接中能够传输双向数据流
6.面向连接：双方需建立连接及进行维护
7.流量控制机制
8.累积确认
9.使用单一的重传定时器(与SR有区别)
10.使用重传保障不丢包，当：超时、收到重复ACK
TCP的段结构：
TCP的主机交互过程:
TCP中超时时间的设置：
估计RTT -> 确定SampleRTT：从段发出至收到ACK的时间(忽略重传) -> EstimateRTT：测量多个SampleRTT，取平均值
公式：
TCP中的发送方：
TCP重传示例：
注意：
1.若发送方收到的ACK大于当前的SendBase，说明有新的数据被确认接收了，则更新SendBase。而此时如果还有没被确认的Segment(指的是更新的SendBase后面的Segment)，需要重新启动计时器。即：
2.接收方采用的是累积重传机制，只显示已经收到的最大的位置。所以上面第二个图中对于已经接收过的seq=92，其返回的是ACK=120
3.发送方丢失了序列号为92的Segment的ACK其实无关紧要，因为接收方采用累积重传机制，发送方真正接收的ACK大于92时(即图中的120)，则说明接收方已经收到了序列号为92的Segment
4.接收方有缓存机制，会把乱序到达的分组缓存起来，而ACK只是显示期望的分组，一旦该期望分组到达接收方，则ACK会自动变成正常的下一个期望的值
接收方采取的动作：
TCP中的快速重传机制：如果发送方收到同一数据的3个ACK，则假定该数据之后的段已经丢失，则在定时器超时之前即进行重传
算法:
思考：为何是3次???
3次重复的ACK是统计的结果。若发送方接收到3次重复的ACK，可能是由于分组是乱序到达造成的，也可能是出现了丢包。根据统计，3次重复的ACK是由于丢包造成的可能性更大，故选定3次重复的ACK作为阈值。
TCP中的流量控制:控制发送方的发送速度，避免淹没接收方(Buffer溢出) -> 一个速度匹配机制
TCP的连接管理：
思考：为什么需要三次握手？
1.避免服务器资源的占用
2.保障消息传输的可靠性
3.两次握手可能会出现死锁
TCP连接图示：
大量客户机接收来自服务器的ACK响应后，不向服务器发送第二个ACK的后果：DDOS攻击之一，向服务器提交大量的请求，使服务器超负荷
TCP连接的关闭:
四次挥手：
Client:“喂，我不说了。”A->FIN
Server:“我知道了。等下，上一句还没说完。Balabala…..”B->ACK
Client:”好了，说完了，我也不说了。”B->FIN
Server:”我知道了。”A->ACK
客户端和服务器端的运作过程：
3.7拥塞控制原理
拥塞的非正式定义：太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理
拥塞的表现：分组丢失(路由器缓存溢出)、分组延迟过大(在路由器缓存中排队)
流量控制：发送方速率过快，以至于接收方处理不了
拥塞的成因与代价：
1.理想情况：路由器有无限缓存
2.路由器带宽有限(入'in是发送方需要重传时的速率)
3.在多跳网络中(数据的传输经过多个路由器)：
拥塞控制的方法：
ATM中的ABR拥塞控制：
TCP的拥塞控制机制：
方法一
AIMD：逐渐增加发送速率，每个RTT将CongWin增大一个MSS，发生loss后将CongWin减半
方法二
慢启动ss：当TCP连接开始时，希望指数性增长
当Conwin达到Loss事件前 值的1/2(threshold)时，将指数性增长切换为线性增长
检测Loss事件：
TCP的拥塞控制算法：
3.8：TCP的性能
TCP的平均吞吐率：
吞吐率与丢包率(loss rate,L)的关系：
TCP的公平性：
具有公平性，向y=x收敛
公平是相对的：
