关注
计网-传输层
三次握手--服务器处于listen
SYN ----SYN ---ACK
客户端 SYN-SENT--发送SYN包，seq =x
服务端-SYN-RECV 结束listen -- 标志位SYN ACK， ack =x+1, seq = y
客户端-ESTABLISHED ----ACK， seq= x +1, ack = y+1
服务端 ESTABLISHED 完成
acknowledgement number , sequence number
四次挥手
FIN ------ACK-----FIN ACK ------ACK--2MSL
客户端 FIN_WAIT-1 ---send FIN, seq = u --- stop sending data
server---CLOSE_WAIT-----send ACK seq = v, ack = u+1
client----FIN_WAIT------wait for continuing data from server
server -----send FIN ACK , ack = u+1, seq = w---then LAST-ACK
client TIME-WAIT ---send ACK
server CLOSE
client wait for 2 MSL --close
如果只有两次握手-第三次服务器无法确定收到-就会超时重传等等
为什么第二次还要返回SYN--因为ACK是确定接收无误，而SYN是同步序列号
为什么需要四次挥手--TCP全双工通信的
因为比如客户端结束传输数据，服务器还有数据传送，所以需要发送ACK+FIN ACK来关闭TCP
SYN ----SYN ---ACK
客户端 SYN-SENT--发送SYN包，seq =x
服务端-SYN-RECV 结束listen -- 标志位SYN ACK， ack =x+1, seq = y
客户端-ESTABLISHED ----ACK， seq= x +1, ack = y+1
服务端 ESTABLISHED 完成
acknowledgement number , sequence number
四次挥手
FIN ------ACK-----FIN ACK ------ACK--2MSL
客户端 FIN_WAIT-1 ---send FIN, seq = u --- stop sending data
server---CLOSE_WAIT-----send ACK seq = v, ack = u+1
client----FIN_WAIT------wait for continuing data from server
server -----send FIN ACK , ack = u+1, seq = w---then LAST-ACK
client TIME-WAIT ---send ACK
server CLOSE
client wait for 2 MSL --close
如果只有两次握手-第三次服务器无法确定收到-就会超时重传等等
为什么第二次还要返回SYN--因为ACK是确定接收无误，而SYN是同步序列号
为什么需要四次挥手--TCP全双工通信的
因为比如客户端结束传输数据，服务器还有数据传送，所以需要发送ACK+FIN ACK来关闭TCP
全部评论
SYN Flood--- DDoS拒绝服务攻击--消耗服务器资源-重复发送SYN给各个端口
造成大量半连接-
解决：
减少半开资源占用时间-辨别恶意IP
核心处理
构造SYN Cache--收到确认传输后再去分配资源
SYN Cookie 直接将半连接信息编码成序列号返回，确认后再分配资源
缺点-没有重传机制--降低正常连接成功率
SYN Proxy 类似于***---代理服务器这样需要代理之后就需要6次连接了
TCP粘包问题
数据大于缓冲区，报文数据大于最大报文长度就会拆包
当分组一起传送，接收赶不上发送就会粘包
消息头部添加消息长度
固定长度-空位补充
使用分隔符
主要是多个没有关系的分组需要处理粘包，有关系的不需要-因为可以seq判断
TCP报文包含---源和目的端口，序号和确认号--首部长度--控制位-SYN FIN---接收窗口--校验和（不出错的）---紧急数据指针、
空选项用于：
TCP连接初始化的时候，需要确认最大报文长度
RTT时间戳
窗口扩大因子
流量控制就是让对方发送不要太快，可变长的滑动窗口机制-通过返回的ACK的接收窗口大小来控制数据量发送的大小--端对端的
拥塞控制就是就是防止大量数据注入网络中-四种算法
慢开始---拥塞窗口cwnd=1,慢慢变大， *2
ssthresh 小于这个慢开始-随后拥塞避免
拥塞避免---每经过一个往返时间按RTT（收到确认报文）--就线性增长1
当网络拥塞开始的时候-就慢开始的ssthresh减半-cwnd=1，重复
cwnd=1, *2---ssthresh---+1/RTT
快重传--立返回重复确认--比如发送msg1234-对方收到134-那么由于2缺失-就会发送三次1的ACK，这时就会快速重发msg2
提高吞吐量-
快恢复---当连续收到3个重复确认的时候--乘法减小--ssthresh减半--
窗口满了就等待-如果丢包-防止死锁--计时器辅助周期性接收查询
TCP 超时重传
定时器---超过就发送RST---太长网络利用率不高-太短会重传太多阻塞
停止等待协议
自动重传请求（Automatic Repeat-reQuest，ARQ）
发送一个分组之后就暂停发送-收到确认之后继续发送
client最大TCP连接数----unsigned short - 2^16---大概6000多----65535-端口0通配符是不使用
server固定监听端口，但是可以client IP* port----2^48
但是一般就是并发10万多
TCP UDP区别
面向连接-传输可靠-字节流-传输效率慢-所需资源多-文件传输邮件传输-首部字节20-60
无连接-不可靠-数据报文段-效率快-所需资源少-即时通讯域名转换--8个字节
TCP定时器--建立连接3秒-重传--保活定时器---FIN_WAIT_2, TIME_WAIT
TCP如何保证可靠的-
数据分块---序列号和确认号---校验和保证传输准确---滑动窗口协议进行流量控制---拥塞控制---ARQ协议收到确认再发下一个分组---超时重传
UDP只有一个socket接收缓冲区，没有发送缓冲区-对方缓存满了就无法接受新的，丢包-没有流量控制和超时重传-所以不可靠
UDP----connect指定新的IP+端口号，bind指定端口
CLOSE_WAIT 保证数据传输完毕--
TIME_WAIT: 发送FIN包之后，或许还有冗余包传送，服务器端口也没关闭，如果立即关闭端口又重新连接，就会读取冗余包
此外--直接关闭，如果服务器没有接收重传-客户端无法回应就会发送RST造成异常
高并发短连接--TIME——WAIT会占据大量端口-无法进行快速的复用端口
使用设置 SO_REUSEADDR 套接字， 优化了SYN的序列号比原来的大以及新的时间戳
这样快速摒弃旧连接
2 MSL（Maximum Segment Lifetime）
确保服务器收到FIN报文
因此重传的FIN报文最晚到达时间是2MSL，否则默认close
握手没有收到数据
第一次客户端发送的没有被收到－－－重发－－超过最大重传次数后系统调用返回－１
第二次客户端没收到服务端的ACK－－－－显然重发－－服务端会阻塞在ａｃｃｐｅｔ（）等待ACK报文
第三次服务端没收到-采取超时重传--系统掉用返回-1， 客户端认为成功，就会直接发送数据
服务器accpet（）不处于监听状态--收到数据会发送RST（reset）报文给客户端解除连接
相关推荐
点赞 评论 收藏
分享
