山有峰顶，海有彼岸，漫漫长路，终有回转，余味苦涩，终会有回甘。别被眼前的磨难打败了，或许光明就在你放弃前的那一刻。带着愉快的心情做一个愉快的梦，醒来后，又是新的一天。
世界上任何的书籍都不能带给你好运，但是它们能让你悄悄的成为你自己的
前言
TCP位于传输层,是一个可靠的连接服务,为了准确的传输数据,TCP采用了三次握手,四次挥手策略. 这里讲的是三次握手
TCP首部格式
TCP首部数据格式,通常是20个字节再加可变字段,其中有6个特殊的标识bit,分别是URG,ACK,PSH,RST,SYN,FIN,位置见下图
| 标识位 | 含义 |
|---|---|
| URG | 紧急指针有效 |
| ACK | 确认序号有效 |
| PSH | 接收方应该尽快将这个报文段交给应用层 |
| RST | 重建连接 |
| SYN | 同步序号用来发起一个连接 |
| FIN | 发端完成发送任务 |
本文中用到的标识位是SYN ACK , 使用的时候bit位设置为1,否则默认为0. 也用到了32位序号(Sequence number)和32位确认序号(Acknowledgment number),这里是用来存放双发的初始序列号(ISN)的.
大写的SYN ACK 代表标志位, 小写的seq代表Sequence number, 小写的ack代表Acknowledgment number,
三次握手
通俗的说
就像两个人打电话,为了确定双方的连接状况就行的以下对话:
A : 喂,我是A,你能听清我说话吗?
B : 你好A,我是B,我能听清你说话,你能听清我说话吗?
A : 你好B,我能听清你说话.
到这里两个人都知道通信质量不错,就开始巴拉巴拉的聊起了天
正常的说
在三次握手过程中,会使用SYN ACK,seq和ack.
第一次握手(客户端): 发送请求,TCP中设置SYN=1 ACK=0,seq设置为本机的ISN.
第二次握手(服务端): 收到客户端的数据之后,同意连接后,发送请求,TCP中设置SYN=1 ACK=1,seq设置为本机的ISN,并将ack设置为客户端的ISN+1
第三次握手(请求端): 接收到服务端信息后, 发送请求, TCP中设置SYN=0 ACK=1,seq设置为本机的ISN+1 ,ack设置为服务器的ISN+1
图如下
示例如下 20.1.0.1是我的电脑,20.1.0.128电脑上的一个虚拟机
在128上使用tcpdump监听ens33(虚拟机网卡)的80(nginx)端口
tcpdump -i ens33 port 80 and host 20.1.0.1 -S -n
复制代码在1电脑上使用telnet请求20.1.0.128的80端口
telnet 20.1.0.128 80
复制代码tcpdump监听日志如下
10:26:24.162036 IP 20.1.0.1.57520 > 20.1.0.128.http: Flags [S], seq 1045570310, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
10:26:24.162273 IP 20.1.0.128.http > 20.1.0.1.57520: Flags [S.], seq 3342867055, ack 1045570311, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
10:26:24.162497 IP 20.1.0.1.57520 > 20.1.0.128.http: Flags [.], ack 3342867056, win 2053, length 0
复制代码针对三次握手的攻击
SYN Flood
当客户端发送了第一次握手之后,不再回应或者失联,服务端仍然会发送SYN+ACK,发现失败了就会重试 多次重试仍然失败之后,服务器才会丢弃这个连接,这个时间约有30s-2min左右(设置不同时间不同). 如果大量的用户模拟此种数据,服务器把所有的资源全部用于响应错误的数据,那么服务器无法正常的响应真实客户的请求,此时客户就会以为服务器出问题了
其他的以后再补充...
结束语
尽信书则不如，以上内容，纯属一家之言，因个人能力有限，难免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激
如果您喜欢我的文章，可以[关注]+[点赞]+[评论]，您的三连是我前进的动力，期待与您共同成长~
作者：ZOUZDC
链接：https://juejin.cn/post/7028963866063306760
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
复制代码