http面试题，三次握手四次挥手

1.三次握手

1.浏览器会发一个同步序列号syn给服务器，通知服务器建立连接。
2.服务器收到后，根据传过来的同步序号syn，返回同步序号syn和ack包。
3.为了证明服务器传过来的信息有效性，浏览器会返回ack包给服务器。

疑惑：为什么三次握手必须是三次呢？
第一种情况：假如只有一次，浏览器发信息过去服务器，服务器能不能通信都不知道，那样不就浪费浏览器资源。
第二种情况：假如两次，假设这种情况 ↓
前提 ，我们要清楚，浏览器发送信号给服务器，这个信号是有时效，如果信号失效，浏览器会再次发送信号给服务器，失效信号得到的返回数据将不再有效。
由于信号的时效性，服务器出现卡顿或者重启的情况。浏览器的第一次等待数据太过长，选择作废第一次请求，执行第二次推送同步信号。
在此情景中，服务器会现后返回两次ack包给浏览器，但是第一次的数据浏览器已经作废了，浏览器只认第二次请求数据的帐。
但是服务器不知道浏览器这样子，哪个有效，哪个无效，假如浏览器不告诉服务器，服务器会认为请求成功，傻傻的等待浏览器发送请求，第二种情况还好，假如出现第一种，不就白白浪费资源。
所以，浏览器收到数据会返回一个ack包给服务器，哪次响应是有效的，这样才不会浪费过多的资源。

2.请求响应

1.建立tcp连接后，浏览器会发送请求（请求方法+请求头+请求体）给服务器，获取对应数据。
2.但是服务器执行到响应是需要时间的，不可能一下子就給你响应数据，想想你的sql查询耗时过长？所以就需要发送一个ack包告诉浏览器。
3.服务器执行成功后就立马返回给浏览器响应数据。
4.浏览器得到响应数据就会返回ack数据包告知服务器。

疑惑：为什么响应后浏览器不发数据给服务器，告诉浏览器收到？假如不告诉，服务器会不停发送响应给浏览器吗？
解释：是有告诉服务器收到，这里就需要四次挥手了。

疑惑：请求到响应可不可以省去服务器发送给用户的ack包？
解释：不能，刚刚也说过浏览器信号的时效性，如果请求收到，到响应返回这个时长过长，浏览器会再次发送请求给服务器。

3.四次挥手

1.当发送请求后，浏览器就会发送final包给服务器要求断开连接了。
2.服务器接收后，也是需要处理完之前的响应，才能进行关闭的。避免浏览器误认为没有发送到服务器，从而进行二次发送。服务器会先发送一个ack包给浏览器，告诉浏览器收到断开请求。
3.等服务器关闭资源后，发送final包给浏览器，表示可以关闭了
4.浏览器收到，也需响应服务器返回一个ack包，然后两边断开连接

疑惑：第四次ack数据包有必要吗？
解释：有必要，服务器发送final包，不确定是否发送到浏览器，就会继续发送，知道收到ack数据包才断开连接。

疑惑：服务器发送ack包和final包期间，这段时间在做什么？
解释：服务器会去判断效应数据是否已经发送。
因为存在网络异常的问题，导致推迟发送。同时也因为浏览器还没接收到数据就向服务器发送final包，这样子服务器没处理完就收到final包了。
所以在这段时间里，服务器会判断数据是否已经发送，发送的话就返回final包给浏览器。

疑惑：服务器发送ack包和final包期间，是怎么知道自己发的响应浏览器已经收到了？
解释：、当发送请求后，浏览器就会发送final包给服务器要求断开连接了。在这个流程里面。浏览器是会接收到响应的，同时是需要返回一个ack包给服务器，告诉数据接收到。服务器会根据自己需要发送的响应数据和自己得到的ack作比较，如果都接收就发送final包给浏览器，没有就其余操作。

疑惑：浏览器怎么判断第一次挥手成功？
解释：浏览器发送final数据包后会进入fin_wait_1状态（第一次等待fin信号），服务器收到会返回ack包，并且进入close_wait状态（等待关闭），如果浏览器一直没收到ack包，就会重复发送fin数据包，直到收到ack包变成fin_wait_2状态（第二次等待fin数据包）。

疑惑：第四次挥手，浏览器知道自己发送成功吗？如果发送失败，服务器不就一直等待？
解释：当浏览器收到fin数据包后，浏览器不会立即关闭连接。会处于2分钟的待机时间。
站在服务器角度，服务器收不到浏览器发送的ack包，会一直发送fin包给浏览器，直到浏览器返回ack包。
在浏览器的待机时间里，它会判断服务器还有没有fin包发过来，有代表发送ack包给服务器失败，没有会自行断开。