一、TCP三次握手,挥手四次?
ACK:确认序号有效。 SYN:发起一个新连接。 FIN:释放一个连接。
三次握手,即建立TCP连接,需要客户端和服务端总共发送至少三个包确认连接的建立。
四次挥手:即终止TCP连接,需要客户端和服务端总共发送4个包确认连接的断开
建立连接
第一次握手
Client将标志位SYN置1,随机产生一个值seq=J,并将数据包发给Server
Client进入SYN_SENT状态,等待Server确认
第二次握手
Server收到数据包后标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置1,随机产生一个值,并将数据包发给Client确认连接请求,Server进入SYN_RCVD状态
第三次握手
Client收到确认后若ACK为1,则将该数据包发送给Server,Server检查ACK为1则连接建立成功,Client与Server进入ESTABLISHED状态完成三次握手,可以传输数据
因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
关闭连接
第一次挥手:
Clien发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
第二次挥手:
Server收到FIN后,发送一个ACK给Client,Server进入CLOSE_WAIT状态。
第三次挥手:
Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
第四次挥手:
Client收到FIN后,Client进入TIME_WAIT状态,发送ACK给Server,Server进入CLOSED状态,完成四次握手。
当收到对方的FIN报文时,仅表示对方不再发送数据但还能接收收据,我们也未必把全部数据都发给了对方,所以我们可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送。
二、 TCP 有哪些状态?
11种 状态
- LISTEN:侦听来自远方的TCP端口的连接请求
- SYN-SENT:再发送连接请求后等待匹配的连接请求(客户端)
- SYN-RECEIVED:再收到和发送一个连接请求后等待对方对连接请求的确认(服务器)
- ESTABLISHED:代表一个打开的连接
- FIN-WAIT-1:等待远程TCP连接中断请求,或先前的连接中断请求的确认
- FIN-WAIT-2:从远程TCP等待连接中断请求
- CLOSE-WAIT:等待从本地用户发来的连接中断请求
- CLOSING:等待远程TCP对连接中断的确认
- LAST-ACK:等待原来的发向远程TCP的连接中断请求的确认
- TIME-WAIT:等待足够的时间以确保远程TCP接收到连接中断请求的确认
- CLOSED:没有任何连接状态
客户端的状态可以用如下的流程来表示:
CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED
服务器的状态可以用如下的流程来表示:
CLOSED -> LISTEN -> SYN收到 -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED
三、在浏览器输入一个URL,按下回车之后会经过哪些流程?
-
DNS域名解析,得到IP地址
DNS解析流程:
1.在主机查询DNS缓存,如果没有就会给本地的DNS发送查询请求
2.本地的DNS服务器向根域名服务器发送查询请求,根域名服务器返回该域名的一级域名服务器
3.该本地服务器给该一级域名服务器发送查询请求,然后依次类推直到查询到该域名的IP地址
-
解析出IP地址后,根据IP地址和默认端口80和服务器建立连接
-
浏览器发出读取文件(URL中域名后边部分对应的文件)的HTTP请求,该请求报文作为TCP三次握手的第三个报文的数据发送给服务器
-
服务器对浏览器的请求作出响应,并把对应的html文本发送给浏览器
-
释放TCP连接(四次挥手断开连接)
-
浏览器解析该HTML文本并显示内容
七层网络模型:
四、TCP如何解决粘包问题?
TCP/IP四层网络模型每层各司其职,消息在进入每一层时都会多加一个报头,每多一个报头可以理解为数据报多戴一顶帽子。这个报头上面记录着消息从哪来,到哪去,以及消息多长等信息。比如,mac头部
记录的是硬件的唯一地址,IP头
记录的是从哪来和到哪去,传输层头记录到是到达目的主机后具体去哪个进程。
-
MTU: Maximum Transmit Unit,最大传输单元。 由网络接口层(数据链路层)提供给网络层最大一次传输数据的大小;一般 MTU=1500 Byte。
假设IP层有 <= 1500 byte 需要发送,只需要一个 IP 包就可以完成发送任务;假设 IP 层有> 1500 byte 数据需要发送,需要分片才能完成发送,分片后的 IP Header ID 相同。 -
MSS:Maximum Segment Size 。TCP 提交给 IP 层最大分段大小,不包含 TCP Header 和 TCP Option,只包含 TCP Payload ,MSS 是 TCP 用来限制应用层最大的发送字节数。
假设 MTU= 1500 byte,那么 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte,如果应用层有 2000 byte 发送,那么需要两个切片才可以完成发送,第一个 TCP 切片 = 1460,第二个 TCP 切片 = 540。
TCP,Transmission Control Protocol。传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议。
其中跟粘包关系最大的就是基于字节流这个特点。
字节流可以理解为一个双向的通道里流淌的数据,这个数据其实就是我们常说的二进制数据,简单来说就是一大堆 01 串。这些 01 串之间没有任何边界。
应用层传到 TCP 协议的数据,不是以消息报为单位向目的主机发送,而是以字节流的方式发送到下游,这些数据可能被切割和组装成各种数据包,接收端收到这些数据包后没有正确还原原来的消息,因此出现粘包现象。
解决粘包的办法:
1、加入特殊标志
2、加入消息长度信息
跟 TCP
同为传输层的另一个协议,UDP,User Datagram Protocol。用户数据包协议,是面向无连接,不可靠的,基于数据报的传输层通信协议。
基于数据报是指无论应用层交给 UDP 多长的报文,UDP 都照样发送,即一次发送一个报文。至于如果数据包太长,需要分片,那也是IP层的事情,大不了效率低一些。UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。而接收方在接收数据报的时候,也不会像面对 TCP 无穷无尽的二进制流那样不清楚啥时候能结束。正因为基于数据报和基于字节流的差异,TCP 发送端发 10 次字节流数据,而这时候接收端可以分 100 次去取数据,每次取数据的长度可以根据处理能力作调整;但 UDP 发送端发了 10 次数据报,那接收端就要在 10 次收完,且发了多少,就取多少,确保每次都是一个完整的数据报。
UDP 是基于数据报的传输协议,不会有粘包问题。
在报头中有16bit
用于指示 UDP 数据报文的长度,假设这个长度是 n ,以此作为数据边界。因此在接收端的应用层能清晰地将不同的数据报文区分开,从报头开始取 n 位,就是一个完整的数据报,从而避免粘包和拆包的问题。
当然,就算没有这个位(16位 UDP 长度),因为 IP 的头部已经包含了数据的总长度信息,此时如果 IP 包(网络层)里放的数据使用的协议是 UDP(传输层),那么这个总长度其实就包含了 UDP 的头部和 UDP 的数据。
IP 层有粘包问题吗?
-
如果消息过长,
IP层
会按 MTU 长度把消息分成 N 个切片,每个切片带有自身在包里的位置(offset)和同样的IP头信息。 -
各个切片在网络中进行传输。每个数据包切片可以在不同的路由中流转,然后在最后的终点汇合后再组装。
-
在接收端收到第一个切片包时会申请一块新内存,创建IP包的数据结构,等待其他切片分包数据到位。
-
等消息全部到位后就把整个消息包给到上层(传输层)进行处理。
IP 层也切片,但是因为不关心消息里有啥,因此有不会有粘包问题。
粘包问题参考资料:硬核图解TCP粘包