#为什么TCP/IP需要三次握手#
2015-06-15 09:25
375 查看
建立连接时:
正常步骤:
主机1向主机2发送连接请求(connect request:CR),并携带一个主机1的初始序列号(CR(seq = x))主机2收到主机1的请求,返回一个确认请求(acknowledge:ACK),携带自己的初始序列号(SYN (ACK = x + 1, seq = y)) 表示告诉主机1,你可以发送序列号x + 1 的包了,我的初始序列号为y
主机1收到了这个SYN包,开始将data打包,并携带(SYN(ACK = y + 1,seq = x + 1))信息,表示告诉主机2,我现在发送序列号为x + 1的包,你可以发送y + 1的包了。
为什么这样做:
至少这样正常的三次交流双方都能够知道并且确认对方初始的序列号,也就是说主机1告诉主机2序列号,主机2回复主机1说收到了你的序列号并告诉主机1我的初始序列号是什么,主机1收到来自主机2的序列号以后,告诉主机2,我也收到你的序列号了。看一下对于特殊情况,这三次握手是如何处理的:
假设主机1向主机2发送一个请求,这个请求在网络中游荡了好久,主机2还没有收到,这是主机1看见没有反应,放弃不再请求,而之前发送的这个请求才到达主机2:
这时主机2会发送一个确认请求给主机1,问问他是否存在这个请求,而主机1回应说我已经放弃这个请求了,所以回复REJECT(ACK = y)拒绝主机2,主机2知道后就不再理会。
假设主机1向主机2发送的CR(seq = x)包以及DATA(seq = y, ACK = z)包都在网络中游荡了很久,而这时主机1已经和主机2建立了可靠的连接(seq = x + 100,ACK = y + 200)
这个时候,主机2收到的CR包将被忽略,而DATA包也会因为序列号不对而被丢弃
假设主机1向主机2发送的CR(seq = x)包以及DATA(seq = y, ACK = z)包都在网络中游荡了很久,而这时主机1与主机2并没有建立连接
这个时候,主机2对与这个过期的CR包,将会发送确认给主机1问问是否真的是有这个包,而对于过期的DATA包,主机2会识别到序列号不对而忽略。
总之,三次握手后能够确保双方都能知道对方的初始序列号,而防止误收数据包的一个关键就是使用序列号进行确认
释放连接时:
也可以看作是三次握手,但不一定是三次,因为存在超时直接中断的情况
双军对垒问题
正常情况:
主机1告诉主机2,我要和你断开连接主机2收到了主机1的断开请求,也发送一个确认,并说我同意和你断开请求
主机1收到了主机2的话说OK,我现在知道你的做法了,然后主机1释放连接,而主机2在收到这个确认信息以后也释放连接。
特殊情况的处理:
当上面第三步主机1向主机2发送的确认包丢失以后,主机1已经释放了连接而主机2没有得到确认,主机2会在一定时间内保持连接,最后超时释放连接当上面第二部主机2向主机1发送的确认断开请求的包丢失以后,主机1在苦等没果以后选择再次发送断开请求
当主机1第一次发送断开请求时主机2收到了,但是主机2在发送确认断开的时候的数据包丢失了,主机1会再次发送请求,但是这个时候主机1发送的多次请求的包都丢失了,这个时候双方主机都会因为超时而断开连接。
![](http://images0.cnblogs.com/blog/729077/201506/150922184663206.png)
来自为知笔记(Wiz)
相关文章推荐
- MapServer 之 发布网络地图服务(WMS-Web Map Service)
- 基于tcpdump的Android智能移动终端数据包捕获完整解决方案
- TCP
- Tornado源码分析之http服务器篇
- 维基百科将默认开启HTTPS以强化安全
- StarWind 模仿 iSCSI 进行网络存储管理
- CentOS网络问题汇总
- Java基础班学习笔记(16)网络编程
- nginx平台初识(二) 浏览器 HTTP 协议缓存机制详解
- nginx平台初识(二) 浏览器 HTTP 协议缓存机制详解
- netstat用法及TCP state解析
- TCP连接出现大量TIME_WAIT的解决办法
- 一起学习CC3200系列教程之TCP ECHO 服务端 selcet
- 菜鸟网络业务支撑平台
- listview+BaseAdapter + AsyncTask异步请求网络 + LruCache缓存图片
- android http通信
- Allegro里隐藏GND或者电源网络的鼠线/ 显示隐藏的鼠线,修改网络颜色
- 【转】HTTP协议详解
- 大学课程--计算机网络
- Ubuntu 编译安装 Linux 4.0.5 内核,并修复 vmware 网络内核模块编译错误