一、tcp协议

二、通信消息类型

三、准备阶段（三次握手）

准备阶段要干什么？

有什么特点？

准备阶段的核心？

（1）准备阶段的数据传输单位

（2）三次握手的过程

1.第一次握手

2.第二次握手

3.第三次握手

四、通信阶段

通信阶段的核心？

（1）通信阶段的传输数据单位

1.报文头（附加信息）

2.报文正文

（2）通信过程

1.简单确认

2.滑动窗口机制确认

3.滑动窗口机制确认特点—协商

4.滑动窗口机制确认特点—重传（断点续传）

5.滑动窗口机制确认特点—缓存

6.滑动窗口机制的现象—百度网盘限速

7.滑动窗口机制（协商）的现象——下载速度先慢后快、然后又慢

五、关闭连接阶段（四次挥手）

（1）发送者a（源）关闭连接

1.第一次挥手（a发起）

2.第二次挥手

（2）接收者b（目标）关闭连接

1.第三次挥手（b发起）

2.第四次挥手

（3）拒绝服务

一、tcp协议

tcp、udp协议，都是传输层的协议

二、通信消息类型

询问syn、回复ack、应答seq

三、准备阶段（三次握手）

准备阶段要干什么？

通信之前进行可靠性确认。类似于我说话你能听到吗，对方回复能听到问我能听到不，我说我也能。

有什么特点？

面相，即实时通信。就像连麦或面对面聊天一样，马上就回复而不是像微信聊天可以半天才回复一句

准备阶段的核心？

收到请回复，确认机制

（1）准备阶段的数据传输单位

数据单位是segment段，又叫报文，准备阶段只有报文头

应用层（http或者ftp之类的协议）封装进来的头信息

source port、desstination port：源、目标的端口

网络层（tcp协议）封装进来的头信息

seqence number：seq序列号【应答】

acknowledge number：ack序列号【回复】

header length：Resv、URG、ACK【回复消息类型，1代表为ack】、PSH、RST、SYN【询问消息类型，1代表是syn同步请求连接消息类型】、FIN【结束通信信号，finish的简称，1代表关闭连接消息类型】

window：窗口数

（2）三次握手的过程

1.第一次握手

a——>b

【询问：我说话能听到吗】发起同步请求连接消息：syn（1个随机生成的序列号，比如100）

2.第二次握手

a<——b

【回复：能听到】回复消息：ack（序列号100+1=101）

【询问：那你能听到我说话不呢】发起同步请求连接消息：syn（1个随机生成的序列号，比如200）

3.第三次握手

a——>b

【应答：好的，我知道你能听到了】应答消息：seq（101+1=102）

【回复：我也能听到你说话】回复消息：ack（200+1=201）

四、通信阶段

通信阶段的核心？

简单确认机制

（1）通信阶段的传输数据单位

数据单位是segment段，又叫报文，包含报文头、报文正文

1.报文头（附加信息）

应用层（http或者ftp之类的协议）封装进来的头信息

source port、desstination port：源、目标的端口

网络层（tcp协议）封装进来的头信息

seqence number：seq序列号【应答】

acknowledge number：ack序列号【回复】

header length：Resv、URG、ACK【回复消息类型，1代表为ack】、PSH、RST、SYN【询问消息类型，1代表是syn同步请求连接消息类型】、FIN【结束通信信号，finish的简称，1代表关闭连接消息类型】

window：窗口数

2.报文正文

（2）通信过程

1.简单确认

简单确认模式不使用滑动窗口，窗口为1。一次通信只发1个报文，然后简单确认1个报文

第1次确认

a——>b

【应答：好的，我知道三次握手成功可以发送报文了】seq（1个随机生成的序列号，比如100）；
发送第1个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（序列号100+1=101）

第2次确认

a——>b

【应答：好的，我知道可以继续发了】seq（101+1=102）
发送第2个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（序列号102+1=103）

第3次确认

a——>b

【应答：好的，我知道可以继续发了】seq（103+1=104）
发送第2个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（序列号104+1=105）

第n次简单确认

2.滑动窗口机制确认

滑动窗口机制的优点？

实现一次发多个包。比如我发一个8GB视频文件，特别大，而以太网传输单位1个数据帧最大才为1500Byte，一次只确认1个包效率太低。开启滑动窗口，设置窗口数为n个，就可以一次确认n个包

滑动窗口机制确认过程？

比如：开启滑动窗口，设置窗口数为5

第1次确认

a——>b

【应答：好的，我知道三次握手成功可以发送报文了】seq（100、101、102、103、104）
发送5个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（104+1=105）<——b

第2次确认

a——>b

【应答：好的，我知道可以继续发了】seq（105+1=106、107、108、109、110）
发送5个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（序列号110+1=111）

第3次确认

a——>b

【应答：好的，我知道可以继续发了】seq（111+1=112、113、114、115、116）
发送5个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（序列号116+1=117）

3.滑动窗口机制确认特点—协商

什么是协商？

每次确认前，都会协商窗口数n的大小

协商的过程？

第1次协商

尝试n=1

a——>b

【应答：好的，我知道三次握手成功可以发送报文了】seq（100）
发送1个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（100+1=101）

第2次协商（增加窗口数）

一次发1个报文没问题，就尝试n=5

a——>b

【应答：好的，我知道可以继续发了】seq（101、102、103、104、105）
发送5个报文

【回复：确认收到了，可以继续发】回复消息：ack（105+1=106）

第3次协商（发生丢包）

一次发5个报文没问题，就尝试n=10

a——>b

【应答：好的，我知道可以继续发了】seq（106+1=107、108、....、116）
发送10个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（本来应该是116+1=117，结果却是110+1=111），发生了丢包

第4次协商（减少窗口数）

一次发10个报文过多了，那就一次少发点。尝试n=8

a——>b

【应答：好的，我知道可以继续发了】seq（106=1=107、108、....、114）
发送8个报文

a<——b

【回复：确认收到了，可以继续发】回复消息：ack（114+1=115）

4.滑动窗口机制确认特点—重传（断点续传）

发送（出现丢包）

a——>b

【应答：好的，我知道可以继续发了】seq（101、102、103、104、105）
发送5个报文

要求重传（断点续传）

a<——b

只收到了101、102、104、105，发生了丢包
【回复：从103开始重新发（因为在102中断了）】回复消息：ack（102+1=103）