1.确认应答机制
由于发送信息的距离可能较远,可能出现后发的信息先到的情况,怎么办?
TCP将每个字节的数据都进行了编号,即为序列号
如何分辨一个数据包是普通数据还是应答数据呢
2.超时重传
由于丢包是一个随机的事件,因此在上述tcp传输的过程中,丢包就存在两种情况
但是在发送方的角度,无法区分这两种情况
无论出现哪种情况,发送方都会进行"重新传输"
所以udp一般延迟比较低
如果a给b发了消息,而b回复的数据丢了,那a就会超时重传一条一样的数据过去
3.连接管理机制
3.1 建立连接,TCP三次握手
TCP在建立连接的过程中,需要通信双方一共"打三次招呼",才能发完成连接建立的
ack和syn同时为一,此时就是三次握手了
3.2 连接断开,四次挥手
建立连接一般是客户端主动发起
断开连接,客户端和服务器都可以主动发起
和三次握手不同,此处的四次握手,不一定能把中间的两次交互合并
不能的原因:ack和第二个fin的触发时机是不同的
ack是内核响应,b收到fin,就会立即返回ack
第二个fin是应用程序的代码触发,b这边调用了close方法才会触发fin
可以的原因:
3.3 问题
3.3.1 怎么判断报文是不是同步报文段?
3.3.2 三次握手要解决什么问题? (核心作用)
这种设定,是避免前朝的剑斩本朝的官
3.3.3 两次,三次握手是否可行?
两次不行,四次可以,但没必要,两个数据合并成一个数据更高效\
4.滑动窗口机制
4.1丢包如何重传
这种情况不用任何重传,因为有确认序号机制
TCP前提是可靠性,在可靠性的前提上,再提高传输效率
5.流量控制
站在接收方的角度,反向制约发送方的传输速率
6.拥塞控制
6.1过程
在指数增长的过程中,如果达到阈值,就从指数增长,变成线性增长
线性增长也是增长,如果传输速率越来越快增长到一定程度,网络上就可能会出现丢包了(网络堵塞)
一旦触发丢包,就把窗口大小缩小,重新进行前面的慢开始 - 指数增长 - 线性增长
并且会根据当前丢包的窗口大小,重新指定线性增长阈值(为了避免指数增长一下就达到丢包阈值)
这是经典版本的拥塞控制,后面tcp又进行了改进
最终时机发送的窗口大小,是取流量控制和拥塞控制中窗口的较小值
7.延时应答
8.捎带应答
在延时应答的基础上,进一步提高效率
9.面向字节流
相比之下,UDP这样的面向数据报的通信方式就没有这样的问题
如何解决粘包问题?
前面写的回显服务器,就是这样的方式
10.异常情况处理
10.1 进程崩溃
10.2 主机关机(正常流程)
10.3 主机掉电
10.4 网线断开
11.TCP的心跳机制
