化妆品备案查询网站,新手学wordpress,wordpress百度地图,WordPress页面调用文章目录
四位首部长度
序号
捎带应答
标记位
超时重传机制
连接管理机制#xff08;RST标记位#xff09;
三次握手及四次挥手的原因 TCP的全称是传输控制协议#xff08;Transmission Control Protocol#xff09;#xff0c;也就是说#xff0c;对于放到TCP发送缓冲…目录
四位首部长度
序号
捎带应答
标记位
超时重传机制
连接管理机制RST标记位
三次握手及四次挥手的原因 TCP的全称是传输控制协议Transmission Control Protocol也就是说对于放到TCP发送缓冲区中的数据如何发什么时候发出错了怎么办这些都是有TCP协议控制的 下面是TCP报文的基本格式 标准报头是20个字节并且在传输层并不会像我们在应用层一样还需要序列化传输层直接发送的就是结构化的数据因为这样发送成本是最低的发送带宽最小。那它不是会有跨平台大小端的问题吗Linux内核中对它进行了处理 不同的客户端都同时可以基于TCP协议向服务器发送信息那么OS中就会存在很多收到的报文这些报文可能正在网络层或数据链路层中还没有拷贝到传输层的接收缓冲区可能就在缓冲区中还没来的及处理总之各种情况 那么OS就要对大量的已经收到的但是暂未处理的报文进行管理如何管理呢先描述再组织 而描述这种报文的结构体就叫做struct sk_buffer它里面存有指针就指向存着报文的内存空间对于每层协议来说报头在前面正文在后面我们如果要剥离报头只需要指针向后移动一定的字节数即可添加报头就是向前移动。所以封装与解包本质就是指针移动然后进行一定操作 四位首部长度 那下面来解释一下TCP报文中的4位首部长度 这个长度指的是报头的20个字节加上选项的长度并且基本单位是为4字节 也就是说4位能表示的最大数字是15即报头选项的最大长度是15*460字节选项的范围是[0,40] 我们都说TCP协议是可靠的它保证可靠性具体体现是什么呢 因为我们发到网络中的消息我们根本不知道它去了哪里我们如果想知道它有没有被对方收到就只能看有没有收到应答 所以我们可以确定的是如果我收到应答那么我发的消息对方肯定收到了。这依靠的就是确认应答机制我收到了消息就要应答 所以可靠性是指我能知道对方收到了我发的消息同时我也得知道对方没收到我发的消息 发送数据和应答这些细节其实都是双方OS完成的这也就是“传输控制协议”中“控制”的一个体现 序号 我们发送数据可以串行发也就是发送一条等应答然后再发下一条等应答……但是这样效率太慢了 我们可以一次发多条但是问题就来了对方也给我很多应答那如果有一条消息对方没收到那我怎么知道是那一条消息呢并且对方怎么判断那条消息在前那条消息在后呢因为我的发送顺序并不一定是对方的接收顺序 这个问题的解决方法就是报头中的序号我们可以给消息带序号对方收到了一堆消息也可以通过排序序号来知道我发的消息的顺序然后再按顺寻处理数据即可所以应答就要把确认序号带上这个确认序号一般是发来消息的序号1 确认序号的含义就是该确认序号之前的数据对方已经全部收到了下次发送请从确认序号开始 我们知道TCP是有发送缓冲区并且TCP是面向字节流的其实我们可以把这个缓冲区看成一个一定长度的char数组那么缓冲区中每个字节其实都有自己的序号这个序号就是下标确认序号我们前面说就是发来的报头中的序号1那么新的序号其实就是确认序号我要发送的报文的长度 捎带应答 TCP是支持全双工的既要向对方发送消息也要向对方发送应答所以需要序号和确认序号两个 如果只发应答只需要发一个报头报头中添加确认序号即可那么我可不可以发送一个报文其中既有应答确认序号又有我想给对方发的数据序号和正文呢当然可以我们叫做捎带应答 标记位 下面我们来解释TCP报头中的标志位 为什么要有标志位呢其实就是区分不同的TCP报文类型 就比如我们知道基于TCP通信时客户端要connect服务器这是发的报文就是建立连接的报文同时还有正常通信的报文还有close时断开连接的报文等等这些报文类型都不同那么为了区分这些报文类型就有了标志位 下面我们简单通过三次握手这个过程来介绍三个标记位ACK确认标记位SYN(同步标记位)FIN断开连接标记位 这个过程是我们在客户端调用connect后OS自动完成的首先客户端向服务器发送带SYN标记位即将此位 置为1的报头服务器收到后向客户端发送SYNACK的报头客户端收到后向服务器发送ACK的报头至此三次握手成功后服务器accept获取连接。我们将服务器置为监听状态是因为只有listen状态的服务器才能受理SYN的请求 双方建立好连接之后是要对这个连接进行管理的用内核数据结构去管理这样就会消耗内存空间和时间。所以说维护连接是有成本的 下面是四次挥手的大致过程这个过程也是OS自动完成的 先调用close的一方A要向对方发送FIN请求对方B收到后会发送ACK之后B会发送FIN请求A收到后发送ACK 超时重传机制 这个机制其实在报头中是没有体现的当我们向对方发送请求时如果我们迟迟都收不到应答我们只能主观的认为对方没收到数据也有可能收到了只不过对方的ACK可能没发过来我们肯定要按最差情况处理此时我们就认为超时了我们需要重传。 也就是说如果我们发送的请求在一个时间段内都没有收到应答就要触发超时重传机制。 那万一对方收到了呢只不过是ACK没发过来因为报头中是有序号的对方可以根据这个序号进行去重 上面说一个时间段内那这是多少时间呢 因为网络的状态是动态的TCP为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个超时时间 Linux超时以500ms为一个单位进行控制等待时间以此是1*5002*5004*500这样以指数形式递增累积到一定的重传次数TCP就会认为网络或对端主机出现异常强制关闭连接 连接管理机制RST标记位 有这样一种情况就是三次握手的第三次ACK发送之后丢掉了这时客户端已经认为建立好连接了但是服务器却没有建立好连接。 此时客户端都可以向服务器发送数据了此时服务器因为没有建立好连接但是收到了数据此时就会向客户端发送带有RST标记位的报头来表示reset重置即重新进行三次握手 所以RST这个标记位就是用来解决建立连接出现异常的问题的 三次握手及四次挥手的原因 三次握手 如果一次就可以握手那太扯了因为客户端连应答都没有收到连最基本的网络连通性都无法确认 两次的话服务器是比客户端先建立连接的维护连接是有成本的如果客户端是恶意连接的疯狂发送SYN请求SYN洪水攻击那么服务器资源就会被浪费从而导致真正想连接的用户无法连接 所以三次握手就是因为 1.需要保证网络信道是健康的三次握手客户端服务器双方都会有一次确定的收发他们就可以确认是全双工 2.确保双方OS是健康且愿意通信的 四次挥手 它的原因其实和三次握手是一样的关键就是四次挥手没有进行捎带应答因为虽然比如客户端关闭连接但是服务器还有消息要发。那么此时用户如何拿取数据呢 首先一般应用层代码是有逻辑的一般按照协议收完消息后才会close其次其实我们可以仅关闭写端不关闭读端是有这样的接口的 如果选项是SHUT_RDWR就相当于close
