面向连接的传输:TCP
面向连接的传输:TCP
传输控制协议(TCP,Transmission Control Protocol)是一种点对点、可靠的、按顺序的字节流(但是没有报文边界)、全双工、有流量控制拥塞控制、面向连接的传输协议。为了在不可靠的互联网络上提供可靠的点到点字节流而专门设计的一个传输协议。
报文段结构
- 序号:报文段首字节的在字节流的编号。
- 确认号:期望从另一方收到的下一个字节的序号,累积确认。
可靠数据传递
TCP在IP不可靠服务的基础上建立了Rdt;结合了上面两种滑动窗口协议。
- 累积确认(像GBN,但是区别在于ACK的序号是期望收到的报文序号)
- 单个重传定时器(像GBN)
- 超时重传(只重发那个最早的未确认段:SR)
- 重复确认重传(收到了3次冗余确认,进行快速重传)
发送方事件
- 从应用层接收数据:
- 用nextseq创建报文段,发送报文启动定时器
- 超时重传:
- 重传后沿最老的报文段
- 重启定时器
- 收到确认:
- 更新已被确认的报文序号
- 如果当前还有未被确认的报文段,重新启动定时器
接收方事件
- 延迟的ACK。对另一个按序报文段的到达最多等待500ms。
- 如果下一个报文段在这个时间间隔内没有到达,则发送一个ACK。
- 如果到达就发送累积ACK指明下一个期待的字节序号。
流量控制
接收方控制发送方,不让发送方发送的太多、太快以至于让接收方的缓冲区溢出。
实现:
- 接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
- 发送方限制未确认字节的个数≤接收方发送过来的rwnd值,保证接收方不会被淹没
会与后面的拥塞控制进行联合控制,缓存区空闲大小和拥塞窗口之间取最小值
连接管理
在正式交换数据之前,发送方和接收方握手建立通信关系。在通信结束后要进行连接关闭。
建立连接(三次握手):
连接建立的本质:
- 知道要和对方通信
- 准备好相关资源
- 控制变量要做置位(特别是连接的初始序号、初始的buffer大小,以免老的数据报对新的有影响)
不能两次握手的原因:
会因为确定连接的延迟到达,重发连接请求造成的半连接问题,浪费了服务器资源
同样因为连接确认的延迟,连接请求重发,并且数据也跟着延迟重发,导致不仅虚假连接发送到服务器上就连重复数据也被一起发送过去了。
正确三次握手:
中间讲对连接请求的确认和我的初始序号合并成一个报文发送给客户端。并且第三次握手有可能会包含正式数据。
- 第三次握手解决了半连接的问题
- 变化的初始序号解决了数据延迟重传的问题
关闭连接(四次挥手):
客户端,服务器分别关闭它自己这一侧的连接发送FIN bit = 1的TCP段。并且一旦接收到FIN,用ACK回应。
本质就是对两个方向的连接进行单独拆除。并且为了避免最后一次确认的丢失问题(因为总是依赖最后一次的确认),客户端在第四次挥手之后还需要进入时间等待状态,结束后才正式关闭连接。
保活定时器:TCP服务器进程每收到一次TCP客户进程的数据,就重新设置并启动保活计时器。若保活计时器定时周期内未收到TCP客户进程发来的数据,则当保活计时器到时后,TCP服务器进程就向TCP客户进程发送一个探测报文段,以后则每隔75秒钟发送一次,若10次都未响应,则服务器直接关闭该连接。
拥塞控制
拥塞的表现:“太多的数据需要网络传输,超过了网络的处理能力”
- 分组丢失(路由器缓冲区溢出)
- 分组经历比较长的延迟(在路由器的队列中排队)
两种常用的拥塞控制方法:
端到端拥塞控制(TCP采用的方法)
端系统根据延迟和丢失事件推断是否有拥塞。
拥塞检测:
- 某个段超时了(丢失事件):拥塞
有关某个段的3次重复ACK:轻微拥塞
速率控制:
- 维持一个拥塞窗口的值:CongWin
- 发送端限制已发送但是未确认的数据量(的上限):
LastByteSent-LastByteAcked <= CongWin
- 粗略地控制发送方的往网络中注入的速率:
rate ≈CongWin/RTT
控制策略:
主要有三个阶段慢启动、拥塞避免、轻微拥塞阶段:
慢启动:从1个开始收到ACK就加倍增长,拥塞后将CongWin降为1,将CongWin/2作为阈值,进入慢启动阶段(倍增直到CongWin/2),到了CongWin/2之后就进入拥塞避免阶段开始线性增长。
如果收到三个重复ACK进入轻微拥塞状态,将CongWin减半并线性增长
网络辅助的拥塞控制(网络负担比较重)
路由器提供给端系统以反馈信息