网络通信协议-TCP协议

数据单位是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）