网站推广通常是从网站建设及运营,彩票网站怎么样建设,软件制作app下载,网站开发过程中遇到的问题网络协议系列文章
网络协议(一)#xff1a;基本概念、计算机之间的连接方式
网络协议(二)#xff1a;MAC地址、IP地址、子网掩码、子网和超网
网络协议(三)#xff1a;路由器原理及数据包传输过程
网络协议(四)#xff1a;网络分类、ISP、上网方式、公网私网、NAT
网络…网络协议系列文章
网络协议(一)基本概念、计算机之间的连接方式
网络协议(二)MAC地址、IP地址、子网掩码、子网和超网
网络协议(三)路由器原理及数据包传输过程
网络协议(四)网络分类、ISP、上网方式、公网私网、NAT
网络协议(五)网络互联模型、物理层、数据链路层
网络协议(六)网络层
网络协议(七)传输层-UDP
网络协议(八)传输层-TCP三次握手、四次挥手原理 目录一、TCP协议二、可靠传输1、停止等待ARQ协议2、连续ARQ协议滑动窗口协议3、SACK选择性确定三、拥塞控制1、慢开始2、拥塞避免3、快重传4、快恢复四、序号、确认号详细步骤五、建立连接三次握手六、释放连接四次挥手网络分层对应的通信协议和数据名称 一、TCP协议 TCP的几个要点 可靠传输流量控制拥塞控制连接管理建立连接、释放连接 数据偏移 占4位取值范围是 0b0101 ~ 0b11115~15乘以4首部长度Header Length首部长度是20~60字节 保留 占6位目前全为0有些资料中TCP首部的 保留(Reserved)字段 占3位标志(Flags) 字段占9位Wireshark中也是如此因为标志位目前只用到了6位所以可以说标识位空闲的3位和保留位3位合并为保留位6位 TCP的一个细节 UDP的首部中有个16位的字段记录了整个UDP报文段的长度首部数据但是TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度并没有字段记录TCP报文段的数据长度 UDP首部中占16位的长度字段是冗余的纯粹是为了保证首部是32bit对齐TCP\UDP的数据长度完全可以由IP数据包的首部推测出来 网络层首部记录着网络层的总长度传输层的数据长度 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度 检验和CheckSum 跟UDP一样TCP检验和的计算内容伪首部 首部 数据伪首部占用12字节仅在计算检验和时起作用并不会传递给网络层 标志位Flags URGUrgent当 URG 1 时紧急指针字段才有效。表明当前报文段中有紧急数据应优先尽快传送ACKAcknowledgment当 ACK 1 时确认号字段才有效PSHPushRSTReset当 RST 1 时表明连接中出现严重差错必须释放连接然后再重新建立连接SYNSynchronization当 SYN 1、ACK 0 时表明这是一个建立连接的请求若对方同意建立连接则回复 SYN 1、ACK 1FINFinish当 FIN 1 时表明数据已经发送完毕要求释放连接 序号Sequence Number 占4字节首先在传输过程的每一个字节都会有一个编号在建立连接后序号代表这一次传给对方的TCP数据部分的第一个字节的编号 确认号Acknowledgment Number 占4字节在建立连接后确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号 窗口Window 占2字节这个字段有流量控制功能用以告知对方下一次允许发送的数据大小字节为单位
二、可靠传输
可靠传输是为了保证包的完整性当有丢包、受到三次重复确认等情况就会重新发包
1、停止等待ARQ协议
ARQAutomatic Repeat–reQuest自动重传请求 疑问重传次数 若有个包重传了N次还是失败会一直持续重传到成功为止么 这个取决于系统的设置比如有些系统重传5次还未成功就会发送 reset报文(RST) 断开TCP连接 2、连续ARQ协议滑动窗口协议
如果接收窗口最多能接收4个包但发送方只发了2个包接收方如何确定后面还有没有2个包 等待一定时间后没有第3个包就会返回确认收到2个包给发送方 A为发送端B为接收端滑动窗口相当于缓存的窗口建立TCP连接时B告诉A接收窗口大小 3、SACK选择性确定
在TCP通信过程中如果发送序列中间某个数据包丢失比如1、2、3、4、5中3丢失了 TCP会通过重传最后确认的分组后续的分组最后确认的是2会重传3、4、5 这样原先已经正确传输的分组也可能重复发送比如4、5降低了TCP性能为改善上述情况发展出了 SACKSelective acknowledgment选择性确认技术 告诉发送方哪些数据丢失哪些数据已经提前收到使TCP只重新发送丢失的包比如3不用发送后续所有的分组比如4、5 SACK信息会放在TCP首部的选项部分 Kind占1字节。值为5代表这是SACK选项Length占1字节。表明SACK选项一共占用多少字节Left Edge占4字节左边界Right Edge占4字节右边界 确认号201期望对方发送201以后得数据段但是把灰色部分数据段排除掉一对边界信息需要占用8字节由于TCP首部的选项部分最多40字节所以 SACK选项最多携带4组边界信息SACK选项的最大占用字节数 4 * 8 2 34 思考为什么选择在传输层就将数据“大卸八块”分成多个段而不是等到网络层再分片传递给数据链路层 因为可以提高重传的性能需要明确的是可靠传输是在传输层进行控制的 如果在传输层不分段一旦出现数据丢失整个传输层的数据都得重传如果在传输层分了段一旦出现数据丢失只需要重传丢失的那些段即可
三、拥塞控制
拥塞控制 防止过多的数据注入到网络中避免网络中的路由器或链路过载 拥塞控制是一个全局性的过程 涉及到所有的主机、路由器以及与降低网络传输性能有关的所有因素是大家共同努力的结果 相比而言流量控制是点对点通信的控制 拥塞控制方法 慢开始slow start慢启动拥塞避免congestion avoidance快速重传fast retransmit快速恢复fast recovery 几个概念 MSSMaximum Segment Size每个段最大的数据部分大小在建立连接时确定 一般是 MTU(1500) - 20 - 20 1460 cwndcongestion window拥塞窗口rwndreceive window接收窗口swndsend window发送窗口 swnd min(cwnd, rwnd) 发送窗口是拥塞窗口和接收窗口取最小的那个
1、慢开始
cwnd的初始值比较小然后随着数据包被接收方确认收到一个ACKcwnd就成倍增长指数级 2、拥塞避免
ssthresh (slow start threshold)慢开始阈值cwnd达到阈值后开始拥塞避免加法增大拥塞避免加法增大拥塞窗口cwind 缓慢增大以防止网络过早出现拥塞乘法减小只要出现网络拥塞把ssthresh减为拥塞峰值的一半同时执行慢开始算法cwnd又恢复到初始值 当网络出现频繁拥塞时ssthresh值就下降的很快 3、快重传
接收方 每收到一个失序的分组后就立即发出重复确认使发送方及时知道有分组没有到达而不要等待自己发送数据时才进行确认 发送方 只要连续收到三个重复确认总共4个相同的确认就应当立即重传对方尚未收到的报文段而不必继续等待重传计时器到期后再重传 4、快恢复
当发送方连续收到三个重复确认说明网络出现拥塞 就执行“乘法减小”算法把ssthresh减为拥塞峰值的一半 与慢开始不同之处是现在不执行慢开始算法即cwnd现在不恢复到初始值 而是把cwnd值设置为新的ssthresh值减小后的值然后开始执行拥塞避免算法“加法增大”使拥塞窗口缓慢地线性增大 四、序号、确认号详细步骤
左边紫色A客户端右边蓝色B服务端①②③建立连接④发送http请求⑤⑥⑦⑧响应http请求⑨应答服务器 注意 s1是客户端的初始值可以理解随机数s2是服务端的初始值这两边给对方发送数据的序号都是从初始值开始计算所以也可以理解原生是s1和s2相对则都是0 SYN ACK表示标记位是否为1seq是序号ack为确认号①客户端请求与服务器建立连接syn1表示客户端第一次发请求也代表建立连接请求 数据部分占0字节这里序号s1其实给服务端用的第一次发所以也没有应答ack0而且只有ACK 1 时确认号字段才有效 ②服务器应答客户端建立连接syn1表示服务器第一次发请求也代表建立连接请求 数据部分占0字节这里序号s2也是给客户端用的这里ack确认s1期望收到s11的字节数据 ③应答②因为②期望收到s11数据那么③序号为s11期望收到②s21数据但是这里数据部分依然还是0字节④建立连接成功后第一次请求数据客户端从s11开始发数据一共k字节期望服务器从s21开始发 ⑤从④中期待的s21数据开始发送其实也就是服务器的第一个字节数 期待客户端从s1k1发因为④中请求发了k个字节 ⑥⑦⑧序号就是前一个数据的序号发送的字节长度ack都一样都是上次http请求的s1k1 ⑨应答服务器发送的⑤⑥⑦⑧序号则是⑤⑥⑦⑧期望的但是这里数据占用0字节其实只是应答没有发数据了 相对序号、确认号 原生序号、确认号 五、建立连接三次握手 CLOSEDclient处于关闭状态LISTENserver处于监听状态等待client连接SYN-SENT表示client已发送SYN报文等待server的第2次握手SYN-RCVD表示server接受到了SYN报文当收到client的ACK报文后它会进入到 ESTABLISHED 状态ESTABLISHED表示连接已经建立 前2次握手的特点 SYN 都设置为1数据部分的长度都为0TCP头部的长度一般是32字节 固定头部20字节选项部分12字节 双方会交换确认一些信息 比如MSS、是否支持SACK、Window scale窗口缩放系数 等这些数据都放在了TCP头部的选项部分中12字节 为什么建立连接的时候要进行3次握手2次不行么 主要目的防止server端一直等待浪费资源如果建立连接只需要2次握手可能会出现的情况 假设client发出的第一个连接请求报文段因为网络延迟在连接释放以后的某个时间才到达server本来这是一个早已失效的连接请求但server收到此失效的请求后误认为是client再次发出的一个新的连接请求于是server就向client发出确认报文段同意建立连接如果不采用“3次握手”那么只要server发出确认新的连接就建立了由于现在client并没有真正想连接服务器的意愿因此不会理睬server的确认也不会向server发送数据但server却以为新的连接已经建立并一直等待client发来数据这样server的很多资源就白白浪费掉了 采用 “三次握手” 的办法可以防止上述现象发生 如果第3次握手失败了会怎么处理 此时server的状态为 SYN-RCVD若等不到client的 ACKserver会重新发送 SYNACK 包如果server多次重发 SYNACK 都等不到client的 ACK就会发送 RST包强制关闭连接
六、释放连接四次挥手
FIN-WAIT-1表示想主动关闭连接 向对方发送了FIN报文此时进入到FIN-WAIT-1状态 CLOSE-WAIT表示在等待关闭 当对方发送FIN给自己自己会回应一个ACK报文给对方此时则进入到CLOSE-WAIT状态在此状态下需要考虑自己是否还有数据要发送给对方如果没有发送FIN报文给对方 FIN-WAIT-2只要对方发送ACK确认后主动方就会处于FIN-WAIT-2状态然后等待对方发送FIN报文CLOSING一种比较罕见的例外状态 表示你发送FIN报文后并没有收到对方的ACK报文反而却也收到了对方的FIN报文如果双方几乎在同时准备关闭连接的话那么就出现了双方同时发送FIN报文的情况也即会出现CLOSING状态表示双方都正在关闭连接 LAST-ACK被动关闭一方在发送FIN报文后最后等待对方的ACK报文 当收到ACK报文后即可进入CLOSED状态了 TIME-WAIT表示收到了对方的FIN报文并发送出了ACK报文就等 2MSL 后即可进入CLOSED状态了 如果FIN-WAIT-1状态下收到了对方同时带FIN标志和ACK标志的报文时可以直接进入到TIME-WAIT状态而无须经过FIN-WAIT-2状态 CLOSED关闭状态 由于有些状态的时间比较短暂所以很难用 netstat 命令看到比如SYN-RCVD、FIN-WAIT-1等 释放连接的一些细节 TCP/IP协议栈在设计上允许任何一方先发起断开请求client发送ACK后需要有个TIME-WAIT阶段等待一段时间后再真正关闭连接 一般是等待2倍的 MSLMaximum Segment Lifetime最大分段生存期MSL是TCP报文在Internet上的最长生存时间每个具体的TCP实现都必须选择一个确定的MSL值RFC 1122 建议是2分钟可以防止发送ACK对方接收不到会重新发送FIN此时还需要应答 如果client发送ACK后马上释放了然后又因为网络原因server没有收到client的ACKserver就会重发FIN这时可能出现的情况是 ① client没有任何响应服务器那边会干等甚至多次重发FIN浪费资源② client有个新的应用程序刚好分配了同一个端口号新的应用程序收到FIN后马上开始执行断开连接的操作本来它可能是想跟server建立连接的 为什么释放连接的时候要进行4次挥手 TCP是全双工模式第1次挥手当主机1发出FIN报文段时 表示主机1告诉主机2主机1已经没有数据要发送了但是此时主机1还是可以接受来自主机2的数据 第2次挥手当主机2返回ACK报文段时 表示主机2已经知道主机1没有数据发送了但是主机2还是可以发送数据到主机1的 第3次挥手当主机2也发送了FIN报文段时 表示主机2告诉主机1主机2已经没有数据要发送了 第4次挥手当主机1返回ACK报文段时 表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接 长连接和短链接 如果建立连接后不需要进行数据交互就会关闭那就是短连接如果建立连接后需要进行数据交互以后再关闭那就是长连接
