TCP报文段结构以及三次握手四次挥手

灵魂拷问

  1：TCP跟UDP的区别？
  2：TCP如何保证包的可靠性？
  3：TCP首部都包含什么鬼东西？
  4：TCP三次握手四次挥手的过程？
  5：TCP为什么握手三次而不是握手四次？为什么要挥手四次？

什么是TCP？

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一对一才能面向连接，一对多是无法简历连接
• 可靠的： 无论网络链路中出现了怎样的变化，TCP都可以保证一个报文一定能够到达接收端。
• 字节流： 消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节已经收到，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

TCP跟UDP的区别？

TCP报文段结构

Snip20200709_34.png

报文段结构说明：

1、源端口号字段，目的端口号字段：占16位。复用和分解上层应用的数据。
2、序号字段、确认序号字段：占32位。
      序号字段：TCP的序号是对每个应用层数据的每个字节进行编号；
              在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号。
      确认序号字段：期望从对方接收数据的字节序号，即该序号对应的字节尚未收到；
                  在建立连接后，确认序号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号。
3、首部长度字段：占4位。指出TCP段的首部长度，以4字节为计算单位。
4、保留字段：占6位。保留为今后使用，目前值为0。
5、URG、ACK、PSH、RST、SYN、FIN各占1位。为标志位字段；
      各占1位，变值为0或1；
      URG（Urgent）：紧急URG=1时，紧急指针字段才有效，表明当前报文中有紧急数据，应优先尽快传输。
      ACK（Acknowledge）：当ACK=1，确认序号字段有效；ACK=0时，确认序号字段无效。
      PSH（Push）：当推送PSH=1，尽快将报文段中的数据交付接收应用迚程，不要等缓存满了再交付。
      RST（Rest）：复位RST=1，TCP连接出现严重差错，释放连接，再重新建立TCP连接。
      SYN（Synchornization）：同步SYN=1，ACK=0时，表明是一个建立连接的过程。若对方统一建立连接，则回复SYN=1，ACK=1.
      终止FIN=1，TCP报文段的収送端数据已经収送完毕，请求释放连接。
6、接收窗口字段：占16位。向对方通告我方接收窗口的大小。
7、校验和字段：占16位。
      计算方法不UDP校验和的计算方法相同。TCP协议号是6。
8、紧急指针字段：占16位。
      URG=1时，才有效。指出在本TCP报文段中紧急数据共有多少个字节。
9、选项字段长度可变，最短为0字节，最长为40字节。
10、填充字段，叏值全为0，目的是为了整个首部长度是4字节的整倍数。

1：建立连接的过程

Snip20200709_27.png

2：为什么需要三次握手

确保客户端，服务器确定双方都能发能收.

第一次握手：客户収送请求，此时服务器知道客户能取。
第二次握手：服务器収送确认，此时客户知道服务器能发能收。
第三次握手：客户収送确认，此时服务器知道客户能收。

标志位字段说明：URG、ACK、PSH、RST、SYN、FIN各占1位
      各占1位，变值为0或1；
      紧急URG=1，紧急指针字段有效，优先传送。
      确认ACK=1，确认序号字段有效；ACK=0时，确认序号字段无效。
      推送PSH=1，尽快将报文段中的数据交付接收应用迚程，丌要等缓存满了再交付。
      复位RST=1，TCP连接出现严重差错，释放连接，再重新建立TCP连接。
      同步SYN=1，该TCP报文段是一个建立新连接请求控制段戒者同意建立新连接的确认段。
      终止FIN=1，TCP报文段的収送端数据已经収送完毕，请求释放连接。

第一次握手：
服务器由LISTEN迚入SYN_RCVD（同步收到）

客户端向服务器发送连接请求控制段：（SYN=1，seq=x）
SYN=1：建立连接请求控制段
seq=x：表示传输的报文段的第1个数据字节的序列号是x，此序列号代表整个报文段的序号。
（补充：sequence number，序号的意思。）

Snip20200709_24.png

第二次握手：
服务器由LISTEN进入SYN_RCVD（同步收到）

服务器収回确认报文段：（SYN=1,ACK=1,seq=y, ack_seq=x+1）
SYN=1：同意建立新连接的确认段
ack_seq=x+1：表示已经收到了序列号为x的报文段，准备接收序列号为x+1的报文段。
seq=y：服务器告诉客户确认报文段的序列号是y。

Snip20200709_25.png

第三次握手：
第三次握手可携带数据。

客户对服务器的 同意连接报文段 迚行确认（ACK=1,seq=x+1,ack_seq=y+1）
seq=x+1：客户此次的报文段的序列号是x+1。
ack_seq=y+1：客户期望接收服务器序列号为y+1的报文段。
当客户収送ACK时，客户端进入ESTABLISHED状态；
当服务收到ACK后，也进入ESTABLISHED状态；

Snip20200709_26.png

四次挥手

确保数据发送完再断开

Snip20200709_32.png

第一次挥手：

客户向服务器収送释放连接报文段：（FIN=1,seq=u）
FIN=1：収送端数据収送完毕，请求释放连接。
seq=u：传输的第一个数据字节的序号是u
客户端状态由ESTABLISHED迚入FIN_WAIT_1（终止等待1状态）

image.png

第二次挥手：

服务器向客户収送确认段：（ACK=1,seq=v,ack_seq=u+1）
ACK=1：确认字号段有效。
ack_seq=u+1：服务器期望接收客户数据序号为u+1。
seq=v：服务器传输的数据序号是v。
服务器状态由ESTABLISHED迚入CLOSE_WAIT（关闭等待）
客户端收到ACK段后，由FIN_WAIT_1迚入FIN_WAIT_2

Snip20200709_29.png

第三次挥手：

服务器向客户収送释放连接报文段：（FIN=1,ACK=1,seq=v+1,ack_seq=u+1）
FIN=1：请求释放连接
ACK=1：确认字号段有效。
ack_seq=u+1：表示服务器期望接收客户数据序号为u+1。
seq=v+1：表示自己传输的第一个数据字节的序号是v+1。
服务器状态由CLOSE_WAIT迚入LAST_ACK（最后确认状态）
[图片上传中...(Snip20200709_31.png-504e74-1594279005869-0)]

第四次挥手

客户向服务器収送确认段：（ACK=1,seq=u+1,ack_seq=w+1）
ACK=1：确认字号段有效。
ack_seq=v+1+1：表示客户期望接收服务器数据序号为v+1+1。
seq=u+1：表示客户传输的数据的序号是u+1。
客户端状态由FIN_WAIT_2迚入TIME_WAIT，等待2MSL时间，迚入CLOSED状态。
服务器在收到最后一次ACK后，由LAST_ACK迚入CLOSED。

Snip20200709_33.png