任丘网站制作公司,网架钢构公司,滨州网站建设公司,小程序开发费用分析1. TCP特点
有连接#xff1a;需要双方建立连接才能通信#xff0c;在socket编程中服务端new ServerSocket(port)需要绑定端口#xff0c;在客服端new Socket(serverIp, serverPort)与服务端建立连接可靠传输#xff1a;确认应答机制#xff0c;超时重传机制面向字节流需要双方建立连接才能通信在socket编程中服务端new ServerSocket(port)需要绑定端口在客服端new Socket(serverIp, serverPort)与服务端建立连接可靠传输确认应答机制超时重传机制面向字节流传输单位是字节全双工双向通信类似双行道
2. TCP的报文格式 源端口目的端口TCP的核心32位序号32位确认序号确认应答机制中引入序号防止后发先至的情况32位序号针对请求数据进行编号32位确认序号只针对ACK报文有效选项该部分可有可无可以有以个选项也可以多个选项选项可以是0个字节最多40个字节4位首部长度描述TCP报头长度单位是4字节那就意味着报头长度最大是60字节1111就是15*460保留位现在没用先占个位置16位窗口大小滑动窗口的大小16位并不是说窗口最大是64kb选项中有窗口大小的扩展因子可以表示更大的窗口16位校验和校验发送和接收的时候数据是否一致 如果是第一次学可能会看懵掉没关系把下面内容看完再来看报文格式你就会很通透 3. 确认应答机制
当男生看到女生的回复后就说明男生发的信息已经成功到达了如果没有收到回复就可以认为上次发的数据丢失了。这就是确认应答机制女生回复的“好的好的”就是应答报文ack。普通报文,ack为0应答报文ack为1 确认应答机制是TCP保证可靠性的最核心机制 当发送多条信息时可能出现下面情况此时女生后发的信息男生先收到让男生误以为女生答应了做他女朋友的请求这是由于网络情况很复杂很有可能“后发先至”。解决方案就是对请求和返回的信息进行编号。TCP是字节流协议编号的时候也是以字节为单位
4. 超时重传
当数据在传输过程中可能会发生丢包因为网络环境很复杂中间要经过很多路由器/交换机某个交换机不但要传输我的数据还要传输别人的数据报有很多很多数据报都要经过这个交换机而交换机转发的能力是有上限的很多数据报都经过该交换机就会达到交换机的转发上限就有可能导致有一部分数据报超时了。类似于堵车当数据丢包的时候就要进行“超时重传”丢包有两种情况一种是数据丢包一种是应答报文丢了
数据丢包
当男生等了一段时间没收到女生的回应后男生又在发了一次。这就是超时重传第一次发生丢包时发送方就会在达到超时时间的阈值之后进行重传。如果重传的数据仍然没响应就会继续重传但是第二次超时的时间比第二次长超时时间是逐渐变大的假设一次丢包的概率10%那两次都丢包的概率就是1%说明网络情况比较差后序在重传大概率也无法成功不如降低传输频率节省点主机开销。如果重传几次后仍然无法传输就会尝试重置TCP连接断开重连如果还是连不上就会释放连接。
ack丢包
站在发送者的角度看只知道没收到ACK无法区分是发的数据丢了还是ACK丢了因此发送者都会重传。如果是ACK丢包发送者又重传就会导致接收方收到两份相同的数据所以TCP会对相同的信息进行去重根据序号进行去重
5. 连接管理
TCP的连接是逻辑上虚拟连接主机A和主机B建立连接主机A的系统内核里有一个数据结构包含了和他连接的是谁IP,端口使用的协议主机B的内核的一个数据结构也记录了和他连接的谁IP,端口使用的协议
5.1 三次握手
A发送syn尝试和B建立连接主机B的内核立即返回ack接收对方的连接内核同时也发送syn尝试和主机A建立连接主机A返回ack接收对方的连接。建立连接的过程有四次数据交互过程只不过主机B返回的ack和syn都是内核同时立即发送的所以看起来就是三次的。 三次握手的意义 投石问路检查当前网络情况是否通畅这个期间并不传输任何业务数据检查通信双方发送能力和接收能力是否正常比如我约妹子打游戏
所以握手必须握三次才能够测试完整
协商一些重要的参数
例如TCP的序号并不是从1开始的通常都是建立连接的时候协商一个数字目的是保证两次连接的序号有差别如果连接断开又快速重连接收方就可以区分当前收到的数据是当前连接的还是上一个连接的。 两个重要的TCP状态 LISTEN服务器启动绑定端口之后new ServerSocket完成)服务器良好可以让客服端连接类似手机信号良好可以让别人打电话给我ESTABLISHED:连接建立好之后的稳定状态类似于电话拨通可以说话了
5.2 四次挥手
通信双方各自向对方申请断开连接再各自给对方回应 四次挥手在某些情况下也会变成三次TCP的捎带应答机制会让ACK晚点发送有可能和FIN结束报文端一起发送 两个重要的TCP状态
6. 滑动窗口
在没有引入滑动窗口之前是一问一答主机A大量的时间都消耗在等待ACK上。因此提高效率的方法就是不等ACK直接发送下一条数据。当然这里说的不等也不是完全不等而是每次批量发送一波数据然后再等一波ACK再发一波数据。这里不需要等待直接发送的数据的量就称为“窗口大小”批量发送4条数据批量等待4条ACK此时窗口大小就是4000字节。注意主机A收到一条ACK就继续发一条数据而不是等所有的ACK都到了才统一发下一组。发生一整波数据如果出现丢包/乱序时怎么办
响应ACK丢了
这里的1001表示小于1001的数据都收到了2001表示小于2001的数据都收到了所以即使返回1001这个ACK丢了下一次返回的2001就说明1-2000的数据已经收到了包括了第一次的数据。这就类似于别人问你现在是高几呀你说我已经大二了。因此ACK丢包不需要任何处理
数据报丢了
在上面的过程中只是把丢的包进行了重传没丢的包没有重传效率比较高因此被称为“快速重传”搭配滑动窗口机制的超时重传 有了快速重传超时重传还有意义吗 在传输数据量很多批量传输时自然是遵守快速重传的方式如果传输的数据很少此时仍然是按照超时重传的方式进行。在滑动窗口中如果是最后一个包丢了就是按照超时重传的方式。 窗口越大发送的速度越快那窗口可以无限大吗 发送的速度快了但是接收方的处理速度跟不上就会导致接收方丢弃一部分数据而TCP需要保证可靠性的TCP就要重传这些数据这就导致了恶性循环。
7. 流量控制
在滑动窗口的基础上对发送速率做出限制的机制根据接收方的接收能力来反向影响发送方的发送速率。接收方的接收速率如何衡量 接收方使用接收缓冲区的剩余空间大小来作为发送方发送速率窗口大小的参考数值 主机B收到的数据就会先放到系统内核的接收缓冲区中所谓缓冲区就是一个内存空间字节数组等待B这边的应用程序通过Socket把数据从接收缓冲区中读取走。这就类似于生产者消费者模型A是生产者往B的接收缓冲区生产数据B的应用程序从缓冲区中消费数据。接收方B收到A的数据后就会在ACK应答报文中把当前接收缓冲区的剩余空间大小的值反馈给发送方。
8. 拥塞控制
流量控制是通过接收方的接收速率接收缓冲区剩余空间大小来衡量发送方的速率。在网络中不仅要考虑接收方还要考虑中间转发节点的情况。如何衡量中间节点的情况 把中间设备视为一个整体通过实验来验证发送速度多少合适。开始的时候发的慢一点如果网络通畅就提高速度提高到一定程度发生丢包了就再降低速度速度降低后发现又通畅了就再提高速度。 9. 延迟应答
基于流量控制引入的提高效率的机制尽量让返回的接收缓冲区空间大一些这样滑动窗口也就大一些效率提高了。
10. 捎带应答
基于延时应答的基础上引入的在4次挥手中说过在某些情况下由于捎带应答机制可以变成3次TCP中只要把数据传输过去对方收到之后就会立即由内核返回一个ack报文响应数据则是在应用程序中负责传输。由于这两操作是不同时机传输的因此不能合并在一起但是延时应答机制让这成为了可能。ACK原本是要立即返回的但是由于延迟应答稍等一会才返回在某些情况下业务也正好在这个时候返回响应此时就可以把这两个报文合二为一了。
11. 面向字节流
面向字节流中存在一个典型问题“粘包问题”举个例子解决方案 要想解决粘包问题就要在应用层协议进行区分只要定义应用层数据协议的时候明确包和包之间的边界即可 1.通过分隔符比如约定使用 ; 作为包结束的标记 2.指定包的长度比如在数据包的开头位置声明长度 自定义应用层协议的几个典型实现像xml,json,http这些都解决了粘包问题
12. TCP的异常处理
程序崩溃
进程异常退出操作系统会回收进程资源包括释放文件描述符表这样的释放操作就相当于调用了对应的socket的close方法执行close就会触发FIN结束报文进一步进行四次挥手。
正常关机
关机的时候系统会强制结束所有用户进程和上述的进程崩溃类似。系统内核会进行文件描述符表的释放操作进一步进行四次挥手
主机掉电 掉电的是接收方
此时发送方不知道对方挂了继续发送数据没有收到ACK发送方就会触发超时重传重传几次还没有应答就会尝试重置连接失败后就会断开连接。
掉电的是发送方
接收方等了一段时间后就会发送一个“心跳包”心跳包是周期性触发的只是一个简单的不携带任何业务数据的包存在的意义就是确认一下对方是否存在如果对方不返回心跳包就说明对方挂了此时就放弃连接了。
网线断开
情况和主机掉电一样只不过通信双方主机是正常的通信双方各自按照上述的两种情况进行13. 常见面试题如何将UDP实现为可靠传输基于UDP的应用层实现确认应答机制引入序列号超时重传机制。
