TCPIP头部信息
-
16位源端口号(Source Port):发送主机中进程的端口号
-
16位目的端口号(Destination Port):接收主机中进程的端口号
-
32位序列号(Sequence Number):每一个包中都包含序列号,序列号被系统初始化为某个随机值ISN。后续的TCP报文段中序号加上该报文段所携带数据的第一个字节在整个字节流中的偏移。例如,某个TCP报文段传送的数据是字节流中的第1025~2048字节,那么该报文段的序号值就是ISN+1025
-
32位确认号(Acknowledgment Number):目的主机返回确认号,使源主机知道某个或几个报文段已被接收
-
四位首部长度(Header Length):由于TCP首部包含一个长度可变的选项部分,所以需要这么一个值来指定这个TCP报文段到底有多长
-
URG标志:表示紧急指针(urgent pointer)是否有效
-
ACK标志:表示确认号是否有效。我们称携带ACK标识的TCP报文段为确认报文段
-
PSH标志:提示接收端应用程序应该立即从TCP接收缓冲区中读走数据,为接收后续数据腾出空间(如果应用程序不将接收到的数据读走,它们就会一直停留在TCP接收缓冲区中)
-
RST标志:表示要求对方重新建立连接。我们称携带RST标志的TCP报文段为复位报文段
-
SYN标志:表示请求建立一个连接。我们称携带SYN标志的TCP报文段为同步报文段
-
FIN标志:表示通知对方本端要关闭连接了。我们称携带FIN标志的TCP报文段为结束报文段
-
16位窗口大小(window size) :是TCP流量控制的一个手段。这里说的窗口,指的是接收通告窗口(Receiver Window,RWND)。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度
-
16位校验和(TCP check sum): 由发送端填充,接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意,这个校验不仅包括TCP头部,也包括数据部分。这也是TCP可靠传输的一个重要保障。
-
16位紧急指针(urgent pointer) :是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此,确切地说,这个字段是紧急指针相对当前序号的偏移,不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。
-
TCP头部选项 :TCP头部的最后一个选项字段(options)是可变长的可选信息。这部分最多包含40字节
TCPIP三次连接建立概述
头部信息,在TCPIP三次连接建立,只需要注意以下5点:
- 16位的源端口号,16位的目标端口号
- 32位的序列号,英文缩写为seq
- 32位的确认号,英文缩写为ack
- 标志位ACK,在连接建立时,个人理解代表确认连接
- 标志位SYN,在连接建立时,代表同步状态
总体流程概述:
- TCPIP三次连接建立,一开始,客户端和服务端状态都是close状态,(服务端close状态并不是正真的关闭,而是指连接未建立,服务端TCPIP状态处于监听状态)
- 客户端某个进程主动发起TCPIP连接请求建立,携带数据包,且连接TCPIP协议头部,SYN标志位设为1,seq序列号设为0,客户端进入一个同步已发送状态;
- 服务端监听接收到客户端连接建立请求,响应给客户端TCPIP建立连接请求确认数据包,且TCPIP数据报头部,SYN同步标准位设为1,ACK连接确认位设为1,seq序列号0,ack=0+1表示确认接收到客户端发送的请求数据包,且客户端下次数据包seq的值得为x+1,服务端进入同步已接收状态;
- 客户端接收到服务端请求建立确认响应,在次发送TCPIP请求连接建立确认的确认,携带TCPIP数据包,且数据报的头部ACK标志位为1,seq=0+1,ack=0+1; 客户端状态进入连接已建立状态;
- 服务端收到客户端第二次请求,则服务端也进入连接已建立状态;
TCPIP为什么是三次握手,不是两次握手,不是四次握手
- 四次握手没必要,因为三次握手已经足够建立连接,传输数据,没必要多浪费一次网络资源
- 假设TCPIP连接建立为二次握手,客户端发送请求连接建立,服务端响应,连接建立双方开始传递数据
- 假设客户端发送第一次连接建立时,这次请求连接,在网络传输中被卡住了,客户端等了一会没收到服务端响应,TCPIP传输协议会在一段时间后没收到服务端响应数据报,在次发送请求数据报,这次没有被卡住服务端响应了,建立连接开始传递数据一会,然后关闭通道,在客户端通道关闭后,服务端接收到客户端第一次发的连接建立请求,服务端则认为连接已经建立,就开始给客户端发送数据包,因为客户端状态是关闭的,服务端就没办法得到客户端响应,因为TCPIP协议会在一段时间后没收到响应数据报,一直在间隔一会就发送响应,浪费网络资源;
- 简单概述就是两次握手,服务端没办法确定客户端状态是否可以接收数据
本文图片来自网络其它文章,本文只是个人理解,有表述错误的地方欢迎回帖纠正