有时候聊天的过程当中,个人网络或者她的网络可能会很差,视频就会卡住,听不到对方的声音,过一下子以后才会恢复。面试
中间双方可能就要不断的确认网络是否恢复,可是有时候会:编程
她:“你能够听到了吗?”服务器
我:“能够了,你呢?”、网络
她:“喂喂,你能够听到了吗?”socket
我:“能够了,我能够听到了,你呢?”tcp
她:“你能够听到了吗?” .....指针
这种状况很蛋疼,那么怎样才能找一个简单的办法,让两我的都确认本身能够听到对方的声音,对方也能够听到本身的声音呢?视频
注:如下情节纯属虚构队列
TCP创建链接为何是三次握手,而不是两次或四次?图片
TCP,名为传输控制协议,是一种可靠的传输层协议,IP协议号为6。
顺便说一句,原则上任何数据传输都没法确保绝对可靠,三次握手只是确保可靠的基本须要。
举个平常例子,打电话时咱们对话以下:
因而有了以下对话: -我:1+1等于几?
她:2,2+2等于几?
我:4
首先两我的约定协议
1.感受网络状况不对的时候,任何一方均可以发起询问
2.任何状况下,若发起询问后5秒还没收到回复,则认为网络不通
3.网络不通的状况下等1min路由器以后再发起询问
对于我而言,发起 “1+1等于几”的询问后
对于她而言,当感受网络状况不对的时候
这样,若是上面的对话得以完成,就证实双方均可以确认本身能够听到对方的声音,对方也能够听到本身的声音!
这个故事能够解释TCP为何要三次握手吗 ... 囧
TCP报文格式图:
上图中有几个字段须要重点介绍下:
(1)序号:Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
(2)确认序号:Ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1。
(3)标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义以下:
(A)URG:紧急指针(urgent pointer)有效。
(B)ACK:确认序号有效。
(C)PSH:接收方应该尽快将这个报文交给应用层。
(D)RST:重置链接。
(E)SYN:发起一个新链接。
(F)FIN:释放一个链接。
须要注意的是:
(A)不要将确认序号Ack与标志位中的ACK搞混了。
(B)确认方Ack=发起方Req+1,两端配对。
SYN(synchronous创建联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
establish 创建,建立
所谓三次握手(Three-Way Handshake)即创建TCP链接,是指创建一个TCP链接时,须要客户端和服务端总共发送3个包以确认链接的创建。在socket编程中,这一过程由客户端执行connect来触发,整个流程以下图所示:
在三次握手过程当中,Server发送SYN-ACK以后,收到Client的ACK以前的TCP链接称为半链接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。SYN攻击就是Client在短期内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,因为源地址是不存在的,所以,Server须要不断重发直至超时,这些伪造的SYN包将长时间占用未链接队列,致使正常的SYN请求由于队列满而被丢弃,从而引发网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击,检测SYN攻击的方式很是简单,即当Server上有大量半链接状态且源IP地址是随机的,则能够判定遭到SYN攻击了,使用以下命令可让之现行:
#netstat -nap | grep SYN_RECV
关于三次握手与四次挥手一般都会有典型的面试题,在此提出供有需求的XDJM们参考:
答:这是由于服务端在LISTEN状态下,收到创建链接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭链接时,当收到对方的FIN报文时,仅仅表示对方再也不发送数据了可是还能接收数据,己方也未必所有数据都发送给对方了,因此己方能够当即close,也能够发送一些数据给对方后,再发送FIN报文给对方来表示赞成如今关闭链接,所以,己方ACK和FIN通常都会分开发送。