目录
一、传输层协议
1.为运行在不同Host上的进程提供了一种逻辑通信机制。
2.端系统运行传输层协议
发送方: 将应用递交的消息分成一个或多个的Segment, 并向下传给网络层。
接收方:将接收到的segment组装成消息，并向上交给应用层。
3.传输层可以为应用提供多种协议：
Internet上的TCP：可靠、按序的交付服务
拥塞控制、流量控制、连接建立
Internet上的UDP：不可靠的交付服务
基于“尽力而为(Best-effort)”的网络层；没有做(可靠性方面的)扩展公
两种服务均不保证：延迟、带宽
二、多路复用和多路分用
分用如何工作？
1）主机接收到IP数据报(datagram)：
每个数据报携带源IP地址、 目的IP地址。
每个数据报携带一个传输层的段(Segment)
每个段携带源端口号和目的端口号
2）主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket。TCP做更多处理
无连接分用？
1）利用端口号创建Socket
DatagramSocket mySocket1 = new DatagramSocket (99111) ;
DatagramSocket mySocket2 = new DatagramSocket (99222) ;
2）UDP的Socket用二元组标识：(目的IP地址，目的端口号)
3）主机收到UDP段后
检查段中的目的端口号；
将UDP段导向绑定在该端口号的Socket；
4）来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket
面向连接的分用？
1）TCP的Socket用四元组标识：源IP地址 源端口号 目的IP地址 目的端口号
2）接收端利用所有的四个值将Segment导向合适的Socket
3）服务器可能同时支持多个TCPSocket。每个Socket用自己的四元组标识。
4）Web服务器为每个客户端开不同的Socket
三、UDP
User Datagram Protocol
1.基于Internet IP协议，实现功能：
复用/分用
简单的错误校验
2.“Best effort”的服务模型，UDP段可能丢失、非按序到达
3.无连接
UDP发送方和接收方之间不需要握手
每个UDP段的 处理独立于其他段
4.UDP为什么存在?
无需建立连接(减少延迟)；
实现简单:无需维护连接状态；
头部开销少；
没有拥塞控制:应用可更好地控制发送时间和速率。
5.常用于流媒体应用：容忍丢失、速率敏感
6.UDP还用于DNS、SNMP
7.在UDP上实现可靠数据传输?
在应用层增加可靠性机制
应用特定的错误恢复机制
8.报文段格式：
9.UDP校验和(checksum)
目的:检测UDP段在传输中是否发生错误(如位翻转)
发送方
1）将段的内容视为16-bit整数。
2）校验和计算:计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和。
3）发送方将校验和放入校验和字段。
接收方
1）计算所收到段的校验和
2）将其与校验和字段进行对比
不相等:检测出错误
相等:没有检测出错误(但可能有错误)
四、可靠数据传输的基本原理
Rdt1.0（理想）:可靠信道的可靠传输，不会发生错误，不会丢弃分组
Rdt2.0:不可靠信道（可能翻转位）；差错检测（利用校验和检）；接收方反馈控制消息（确认机制ACK、NAK，停等协议）；重传。
Rdt2.1:增加序列号；需校验ACK/NAK消息是否发生错误。
Rdt2.2:无NAK消息协议；显式地加入被确认分组的序列号。
Rdt3.0:定时器；
五、滑动窗口协议
用滑动窗口协议实现流水线机制。
GBN和SR
| GBN | SR | |
| 特点 | 累计确认（发送拥有最高序列号的、已被正确接收的分组的ACK） | 单独进行确认，为每个分组设置定时器。 多了接收方窗口。 |
| 超时事件 | 重传序列号大于等于n，还未收到ACK的所有分组。设置一个计时器。 | 只重传超时的分组，并为每个分组设置定时器。 |
| 分组乱序到达 | 丢弃，并重新确认序列号最大的、按序到达的分组。 | 缓存机制，缓存乱序到达的分组（在窗口范围内） |
| 发送方 | 首先将数据按定义的格式打包。发送分组，等待确认分组到达。如果发生超时，则重发分组。当收到ACK时， 若收到重复确认, 此处应当立即重发；若没有重复，滑动窗口则向后移动。当确认到最后一个 分组时，结束。 | 将窗口中数据发出，如果超时，则重传并重新设置计时器；如果传输窗口中数据 分组乱序到达，也能将数据分组缓存，如果窗口最小序列号的分组被确认，则窗口滑动。 |
| 接收方 | 当接收到数据传输时，因为是累积确认，所以要判断当前到达的序列号是否是期待的序列号，同时如果检查校验和未出错，则产生确认分组，返回确认分组并期待下一个序列号分组，同时滑动窗口；如果出错或者数据包丢失，收到的不是所期待的数据分组，则重复发送ACK；如果最后一个数据包确认即标志位为1的数据包被确认，结束。 | 接受到接受窗口中的数据则会返回ACK确认，不在窗口中的数据不接收；如果窗口最小序列号的分组被接受，则窗口滑动。 |
SR困境：如图
此时，无法区分序号为0的分组是重传还是下一个数据。
序列号空间大小与窗口尺寸关系：Ns+Nr<=2^k
六、面向连接传输协议-TCP
概述：点对点；可靠的、按序的；流水线机制；发送方/接收方缓存；全双工；面向连接；流量控制机制；拥塞控制机制
TCP段结构
注：
序列号：segment中第一个字节的编号，不是segment的编号；建立TCP连接时，双方随机选择序列号。
ACKs：希望接收的下一个字节序列号；该序列号之前所有的字节均已被正确接收。
举例：
关于超时和重传：
定时器超时时间设置
累积确认
单一重传定时器：与SR不一样
快速重传机制：发送方收到同一数据3个ACK
TCP流量控制：
告诉发送方还有多少；Receiver告知Sender RcvWindow=0，发送方仍然可以发送一个很小的段携带回新的RcvWindow信息，可以避免死锁。
TCP连接管理：
三次握手：
第一次：客户端向服务器端发送TCP SYN段
选择初始序列号；不携带数据；SYN=1，表示要建立连接；
第二次：服务器端收到SYN，回复SYNACK段
服务器分配缓存；选择初始序列号
第三次：客户端收到SYNACK，回复ACK段
并包含数据；SYN=0，表示确认我收到同意建立连接的报文段。
注：ACK表示我想要的下一个段。
例：
关闭连接：
第一步：客户向服务器发送TCP FIN控制端；
第二步：服务器收到FIN，回复ACK，关闭连接，发送FIN；
第三步：客户收到FIN，回复ACK；进入等待状态，如果再次收到FIN，重新发送ACK
第四步：服务器收到ACK，真正连接关闭
例：
拥塞控制原理：
表现：
分组丢失（路由器缓存溢出）
分组延迟过大（在路由器缓存中排队）
拥塞控制方法：
1）端到端拥塞控制
网络层不需要显式的提供支持
端系统通过观察loss，delay等网络行为判断是否发生拥塞
TCP采用这种方法
2）网络辅助的拥塞控制
拥塞指示：SNA，DECbit，TCP/IP ECN，ATM
路由器向发送方显式地反馈网络拥塞信息
指示发送方应采取何种速率
案例：ATM ABR拥塞控制
ABR
弹性服务
如果发送方路径没有拥塞，使用可用带宽
如果发送方路径拥塞，将发送速率降到最低保障速率
RM cells
发送方发送
交换机设置RM cell位（网络辅助）
NI bit：rate不许增长
CI bit：拥塞指示
RMcell由接收方返回给发送方
TCP拥塞控制原理：
发送方限制发送速率：
LastByteSent-LastByteAcked<=CongWin
CongWin：
动态调整以改变发送速率；反映所感知到的网络拥塞
感知网络拥塞：
Loss事件：timeout或收到3个重复ACK
发生loss事件后，发送方降低速率
合理地调整发送速率：
AIMD（加性增-乘性减）、SS（慢启动）
AIMD（加性增-乘性减）
线性加：每个RTT将CongWin增大一个MSS（拥塞避免）
乘性减：发生loss后将CongWin减半
SS（慢启动）
当连接开始时，指数增长
转换：
当CongWIn达到loss事件前值的一半时，从指数增长切换为线性增长；
Loss事件发生时，如果是3个重复ACK：CongWin切到一半，然后线性增长；Timeout事件：CongWin直接设为1个MSS，然后指数增长，达到threshold后，再线性增长。
TCP性能分析
TCP吞吐率（粗略）
给定拥塞窗口大小和RTT，TCP的平均吞吐率时多少？（忽略SS）
假定发生超时时CongWin大小为W，吞吐率是W/RTT；
超时后，CongWin=W/2，吞吐率是W/2RTT；
平均吞吐率0.75W/RTT；
TCP具有公平性
与UDP一起时不保证公平性，多个TCP时也不保证公平性。