网络模型和TCP协议

最新推荐文章于 2024-01-29 13:54:37 发布

技术人Q

最新推荐文章于 2024-01-29 13:54:37 发布

阅读量151

点赞数

分类专栏： java 文章标签： TCP 三次握手网络协议 HTTP

本文链接：https://blog.csdn.net/zlx510tsde/article/details/115427119

版权

java 专栏收录该内容

19 篇文章 1 订阅

订阅专栏

1、网络模型

从上面的表格中可以看到，HTTP是应用层协议，TCP是运输层协议，根本不在一个维度上。

2、TCP

2.1、TCP/IP模型

2.2、TCP连接

TCP建立的连接是可靠的，只要不主动断开就一直存在，且传输的数据是有序的，可靠的，不丢失的，不重复的。

数据传输过程：

1、连接建立(三次握手)

主机A的TCP向主机B的TCP发送连接请求报文段，报文段中包含SYN=1，同时选择一个序号 x,表明在后面传送数据时的第一个数据字节的序号是 x+1

主机B收到连接请求报文段后，如果同意连接，发送确认报文段，在确认报文段中，把SYN和ACK都设为1，确认号ACK=x+1(告诉主机A传送数据时序号从x+1开始)，同时也给自己选一个序号 y

主机A收到确认报文后，也要给B发送确认报文段，告诉主机B，ACK设为1(确认收到消息)，确认号为 y+1 ,自己的需要是 x+1

2、传输数据

TCP连接，应用程序不断的把数据写入到TCP缓存中(可以理解为byte数组),TCP 从缓存中取出一定量的数据，组成TCP报文段(segment)逐个传送给IP层。

接收端从IP层收到TCP报文段后，先存入接收端缓存中，然后接收端的应用进程从缓存中将数据块逐个读取。接收端每收到一部分数据，就会向发送端发送序号(我已经收到了第500个字节的数据)，发送端会根据这个序号，发送序号后的数据。

发送报文示意图：

这种情况，就会产生TCP的粘包拆包问题。应用程序发送了10条数据，依次写到缓存中。这些数据包装成的报文段可能是1个，也可能是5个。接收端应用程序从缓存中获取的数据，不知道怎么区分这10条数据。

示例：发送端发送的数据，10次hello。

hellohellohellohellohellohellohellohellohello

接收端收到的消息可能是：

hellohellohel

lohellohell

ohellohell

ohell

ohello

解决这个问题的方法就是自定义发送接收数据的协议。比如在hello前面再加一个数字，标识发送的数据长度。

5hello5hello5hello5hello5hello5hello5hello5hello5hello

接收端根据协议，先读数字，得到5，然后读后面的5个字节。如果数据不够5个字节，等待。下次继续读。

使用netty中的过程中TCP粘包拆包问题就是这么解决的。关键的解码器 ReplayingDecoder

基本原理:

使用了特殊的ByteBuf，叫做ReplayingDecoderByteBuf，扩展了ByteBuf 重写了ByteBuf的readXxx()等方法，会先检查可读字节长度，一旦检测到不满足要求就直接抛出 REPLAY(REPLAY继承ERROR) ReplayingDecoder重写了ByteToMessageDecoder的callDecode()方法，捕获Signal并在catch块中重置ByteBuf的readerIndex。继续等待数据，直到有了数据后继续读取，这样就可以保证读取到需要读取的数据。

TCP是基于流的，只保证接收到数据包分片顺序，而不保证接收到的数据包每个分片大小。因此在使用 ReplayingDecoder时，即使不存在多线程，同一个线程也可能多次调用decode()方法。在decode中修改ReplayingDecoder的类变量时必须小心谨慎。

3、连接释放(四次挥手)