TCP详解

TCP介绍

tcp是如何利用ip才达到自己的目的:
IP的特点
TCP将应用程序的传输数据分割成合适的数据块
定时器:发包就开始计时,当发送多次消息都没反馈时再告诉应用程序结果
延迟确认:10次包通过一次确认
检验和:检验数据有无错误
流量控制:客户端和服务器会预先分配数据大小,防止发送太多

TCP首部

一般20个字节
socket:ip地址+端口号
在这里插入图片描述
前两个字节资源端口号,后两个字节目标端口号
sequence number:将数据分割成数据块
acknowledgment number:确认有关
12-16字节:三次握手相关 dataoffset:守护长度 reserved:预留将来使用 URG:紧急指针有效(会优化处理该部分数据,打上1就会检查urgen pointer上的数据)ack:确认控制 psh:要尽快转交数据给应用层 RST:重新建立连接 SYN:要建立连接 FYN:结束连接
windows size:控制TCP确认能够发送多少字节
checksum:检验和,检验数据可行性(可选)
options:做额外的解释(如:最长包体大小)

TCP的状态变迁

TCP状态:
在这里插入图片描述
tcp状态变迁:
在这里插入图片描述
进入time_wait状态时socketpair是不可用的,一定要等待time_out时间才进入close状态才能再次复用socketpair,客户端本身socket用得比较少不怕浪费,服务器用得比较多会浪费资源。
服务器从listen到closed状态:比如加载配置文件数据出错
listen到syn_send状态:服务器从被动监听状态直接变到主动连接发消息状态,一般不会出现,有可能代码编码里出现了错误
出现RST复位:请求时间超时;或请求的端口不存在;或应用程序有BUG,某些情况会误认为客户端问题不再处理,此时一部分消息处理一部分没消息就会发;或服务器客户端正在保持连接,客户端需要自己做事情不需要跟服务器交互了,服务器此时如果宕机客户端并不知道,客户端再向服务器发送消息服务器无法接收的,这时服务器会向客户端发送rst告诉客户端需要重置了。
listen会有队列保存三次握完手的socket,此时客户端会认为已经连接成功会向服务器发送消息,此时服务器并没办法处理就会先存起来等待应用程序处理。如果队列完了一般不会发错误信息会通过超时的方式告诉客户端连接不上。
established成功建立连接后数据传输方式:一部分是小数据传输(交互式),成块(下载文件、传送文件)

TCP连接建立(三次握手):

在这里插入图片描述
对应用程序来说socket连接的建立是没法控制的,比如服务器需要限制某些地方的连接,在服务器应用程序上做是比较废的,因为当确认要不要连接时本身socket连接已经建立了,无非就是当accept返回时检查对方socket是不是需要屏蔽的,如果需要屏蔽就主动关闭。如果服务器主动关闭需要time_wait状态。

TCP连接断开:

在这里插入图片描述
为什么要四次挥手:TCP是全双工连接,两者无相互关联,一方可以只发送不接收或只接收不发送。都需要发送关闭消息交给对方确认。
time_wait:TCP需要每个报文的最大的最大生成时间,每个数据包会在网络上存活一段时间,time_wait保证这些数据包的失效。保证下一次连接不会和上一次连接产生数据上的混乱。对服务器来说进入time_wait状态会让客户端无法连接。

TCP数据交互:

在这里插入图片描述
时间延时:跟acknowledgment number确认有关,有可能三个消息一次确认掉了
nagle算法:当数据达到一定长度时才发送,有时需要关闭可能就需要发送小的数据
接收窗口大小:windows size防止较快的机器把较慢的机器冲跨,windows默认8192个字节

其他相关的内容

tcp内部使用的定时器:
在这里插入图片描述
重传定时器:当一个客户端发消息超过一定时间没有确认也没有返回错误,当一个包的生存时间过了,TCP内部会认为对方可能没有收到消息,通过这个定时器来重发消息
坚持定时器:窗口数据太多暂时不能处理了,通过这个计时器询问窗口是否可以接收数据
保活定时器:TCP全双工的,假如一方不传信息不能确认对方是否还连接,通过这个定时器询问对方是否还连接。一般不使用,可以去应用层定时刷新
2MSL定时器:保证延时的数据包在网络中消逝。

wireshark工具:
用wireshark工具查看TCP连接和断开
网络包探测软件
官网https://www.wireshark.org

常见的一些问题:

TCP头部为什么放的是端口信息?
TCP消息到达时会根据端口信息确认有没有应用程序来接收

三次握手有没有可能被恶意使用?
客户端不发ACK,服务器就悬挂起来了。发了syn就不发其他东西了,服务器就要分配很多资源来处理。比如DOS攻击只能通过防火墙抵御。本身应用程序并不能抵御,根本没有到应用层。

消息确认机制有没有弱点:
以前有过类似攻击,发送的消息被其他机器截获了,此时A以为是在和B通信,实际上在和C进行通信

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值