1.TCP协议
为什么需要 TCP 协议 ?TCP 工作在哪一层?
IP网络层是不可靠的,TCP工作在传输层,保证数据传输的可靠性。 TCP全称为 “传输控制协议(Transmission Control Protocol”)。
TCP 是面向连接的、可靠的、基于字节流:
- 面向连接:一定是「一对一」才能连接,不能像 UDP 协议可以一个主机同时向多个主机发送消息,也就是一对多是无法做到的;
- 可靠的:无论的网络链路中出现了怎样的链路变化,TCP有很多策略 都可以保证一个报文一定能够到达接收端;
- 字节流:用户消息通过 TCP 协议传输时,消息可能会被操作系统「分组」成多个的 TCP 报文,如果接收方的程序如果不知道「消息的边界」,是无法读出一个有效的用户消息的。
2.TCP协议格式详解
-
源端口号和目的端口号:表示数据是从哪个进程来, 到哪个进程去。通过端口号将报文交付给上一层
-
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节)。4个比特位[0000 -1111]最大是15再乘以4个字节(单位),一共能表示60个字节。报头长度 = 固定长度(20字节) + 选项。通过4位TCP报头长度就可以将一个完整报文的报头和有效载荷分离。
-
窗口大小:通过read这样的接口,是将用户级缓冲区的数据拷贝都系统级缓冲区中,主机再将数据通过网络发送到目标主机,其实网络的发送本质也是拷贝。那么如果数据一直发,对方没有来得及接收,大量的数据"打满"了接收缓冲区导致数据丢包的问题,这是一种不可靠的表现。TCP保证可靠性,通过16位窗口大小来填写自己接收缓冲区的剩余空间,告知对方进行流量控制。
窗口的大小如何告知对方
Client向Server发送数据,Server收到报文会应答。应答也是基于TCP协议通信的,必须是一个完整的TCP报文(可以没有数据,但至少是完整的报头)!窗口大小通过应答报文告知Client,当然TCP会有**捎带应答(Server也要发送数据捎带的将窗口大小告知对方(数据+应答))**的机制,有可能不会发送单独的应答报文。
-
序列号:用来解决网络包乱序问题。
-
确认序列号:表示确认序列号之前的数据,已经全部收到,下次发送请从确认序列号指定的数字开始发送。
序列号和确认序列号的理解
TCP为了提高效率,不会串行化的传输数据,而是Client发送一批数据给Server。那么Server无法得知报文的顺序而导致数据包乱序的问题,而乱序本身就是一种不可靠的表现。所以通过序列号,按序接收就能保证顺序问题。
Server对Client发送而来的数据序列号+1,响应确认序列号。表示确认序列号之前的数据,已经全部收到,什么意思呢,如:Server响应2001表示前面发送的2000个字节的数据都收到了,所以允许1001应答报文丢失。确认序列号允许少量的应答报文丢失(这里不携带数据),如果是数据丢失会有重传的机制。
当然序列号的初始值,是在建立连接时由计算机生成的随机数作为其初始值,通过 SYN 包传给接收端主机,每发送一次数据,就「累加」一次该「数据字节数」的大小。
HTTP中会定义一个用户级的缓冲区,想象成一个大数组。系列号会根据数组的下标来确定会更好理解。
-
6个标记位:区分TCP报文的类型
TCP通信需要建立连接,建立完成之后才是正常通信,通信完毕后会断开连接。**不要扯什么,无论是建立连接的报文、正常通信的报文、还是断开连接的报文,都是一个完整的TCP报文!**如何区分是哪种类型的报文呢,这就可以根据报文中的标记位来区分。
-
SYN:设为
1
时,表示希望建立连接(称为同步报文段),并在其「序列号」的字段进行序列号初始值的设定 -
ACK:设为
1
时,「确认应答」的字段变为有效;TCP 规定除了最初建立连接时的SYN
包之外该位必须设置为1
。 -
FIN :设为
1
时,表示今后不会再有数据发送,希望断开连接。 -
RST : 设为
1
时,对方要求重新建立连接; 把携带RST标识的称为复位报文段 -
PSH:设为
1
时,提示接收端应用程序立刻从TCP缓冲区把数据读走。Client一直向服务器发送数据,有可能服务器,很繁忙没来得及读取接收缓存的内容,PSH字段提示接收端应用程序立刻从TCP缓冲区把数据读走;但如果有一个极端,应用程序就没有读取数据的方法,那这不扯了吗,要设计一个程序通信,结果又不读取数据,这像什么话啊!
-
-
URG:设为
1
时,紧急指针有效Server服务器负载过大,无法处理Client发来的普通报文,因为报文需要按序排队。但又想知道Server在处理什么工作,可以在编码时设置MSG_OOB(如:1表示IO操作)这样的属性,然后将URG设置为1,让这个报文的紧急字段指向的数据有效,插队处理。
16位紧急指针字段表示紧急数据的首地址,紧急数据不能太大,一般是首地址往后的1个字节
3.TCP的三次握手和四次挥手
3.1.TCP的握手过程
这个地方参照的是小林哥的博客
- 一开始,客户端和服务端都处于
CLOSE
状态。先是服务端主动监听某个端口,处于LISTEN
状态。 - 客户端会随机初始化序号(
client_isn
),将此序号置于 TCP 首部的「序号」字段中,同时把SYN
标志位置为1
,表示SYN
报文。接着把第一个 SYN 报文发送给服务端,表示向服务端发起连接,该报文不包含应用层数据,之后客户端处于SYN-SENT
状态。 - 服务端收到客户端的
SYN
报文后,首先服务端也随机初始化自己的序号(server_isn
),将此序号填入 TCP 首部的「序号」字段中,其次把 TCP 首部的「确认应答号」字段填入client_isn + 1
, 接着把SYN
和ACK
标志位置为1
。最后把该报文发给客户端,该报文也不包含应用层数据,之后服务端处于SYN-RCVD
状态。 - 客户端收到服务端报文后,还要向服务端回应最后一个应答报文,首先该应答报文 TCP 首部
ACK
标志位置为1
,其次「确认应答号」字段填入server_isn + 1
,最后把报文发送给服务端,这次报文可以携带客户到服务端的数据,之后客户端处于ESTABLISHED
状态。 - 服务端收到客户端的应答报文后,也进入
ESTABLISHED
状态。
总结
任何一个网络协议都无法保证100%的可靠性!TCP建立连接的时候最后一个ACK应答,没有没有应答的,如果有应答有应答,那就衍生了鸡生蛋蛋生鸡的问题。但是三次握手能保证局部的可靠性。
为什么是三次握手?不是两次?四次?
首要原因是为了防止旧的重复连接初始化造成混乱
客户端先发送了 SYN(seq = 90)报文,然后客户端宕机了,而且这个 SYN 报文还被网络阻塞了,服务端并没有收到,接着客户端重启后,又重新向服务端建立连接,发送了 SYN(seq = 100)报文(注意!不是重传 SYN,重传的 SYN 的序列号是一样的)
其实,三次握手服务器最后才进入ESTABLISHED,通过这样奇数次连接的方式,如果建立过程中的报文丢失,都可以将失败的成本嫁接到客户端。 另外三次握手保证了通信的全双工验证,保证通信的局部可靠,还有就是可以同步双方初始序列号等。
无论是一次还是两次,客户端向服务端请求连接,SYN到达服务器就立马ESTABLISHED状态,服务器需要创建对应的内核数据结构维持连接,有明显的SYN洪水的问题。
而为什么不是四次,其实也可以是四次,但是TCP有捎带应答的机制,服务器向客户端发送SYN时捎带了ACK。说白了三次握手的最小次数的连接。