计网-传输层

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

相关推荐

04-13 18:10
门头沟学院 Java
想熬夜的小飞象在秋招:被腾讯挂了后爸妈以为我失联了
点赞 评论 收藏
分享
Ncsbbss:又想干活又想要工资,怎么什么好事都让你占了
点赞 评论 收藏
分享
评论
1
3
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务