目录：
1.TCP连接时的三次握手
2.TCP断开时的四次挥手
3.TCP和UDP的异同
4.TCP并发
TCP连接时的三次握手
三次握手的过程
为什么要有三次握手，因为如果只有两次握手，那么
第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态
第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态
第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。
握手中安全问题
SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。
三次握手过程中出现丢包
第一个包发送过程丢失
A会周期性超时重传，直到收到B的确认
第二个包发送过程丢失
B会周期性超时重传，直到收到A的确认
第三个包发送过程丢失
A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：
- 如果此时双方都没有数据传输，会进行第二步，B会周期性超时重传，直到收到A的确认，然后TCP也变成ESTABLISHED，双方开始数据传输。
- 如果A有数据需要发送，由于A已经单方面进入TCP的ESTABLISHED状态，因此A直接传输数据，B收到A的数据包+ACK包后会却换到ESTABLISHED状态，开始接受数据包，然后开始数据传输
- 如果B有数据需要发送，由于B处于半连接状态，数据发送不了，只会周期性超时重传，直到收到A的确认才会传输数据
为什么要三次握手
TCP断开时的四次挥手
四次挥手的过程
第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态
第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态
第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态
第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手
为什么要四次挥手
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。
- FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
- FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
- CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
- LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
- TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
- CLOSED: 表示连接中断。
TCP和UDP的异同
| TCP | UDP | |
|---|---|---|
| 是否连接 | 面向连接 | 面向非连接 |
| 传输可靠性 | 可靠 | 不可靠 |
| 应用场合 | 少量数据 | 大量数据 |
| 速度 | 慢 | 快 |
| 数据正确性 | 保证 | 可能丢包 |
| 数据顺序 | 保证 | 不保证 |
TCP并发
- 网页中的图片资源为什么分放在不同的域名下？
- 浏览器与服务器建立一个TCP连接后，是否会在完成一个http请求后断开？什么条件下会断开？
- 一个TCP连接可以同时发送几个HTTP请求？
- 浏览器http请求的并发性是如何体现的？并发请求的数量有没有限制？
答案解析：
1.网页中的图片资源为什么分放在不同的域名下?
浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。
2.浏览器与服务器建立一个TCP连接后，是否会在完成一个http请求后断开？什么条件下会断开？
在HTTP/1.0中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段Connection: keep-alive，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。
第一次访问有初始化连接和SSL开销
初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。
HTTP/1.1将Connection写入了标准，默认值为keep-alive。除非强制设置为Connection: close，才会在请求后断开TCP连接。
所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置Connection: close才会在请求后关闭TCP连接。
3.一个TCP连接可以同时发送几个HTTP请求？
HTTP/1.1中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。
HTTP2提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。
4.浏览器http请求的并发性是如何体现的？并发请求的数量有没有限制？
页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。
Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。
补充
如果图片都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用HTTP2的Multiplexing功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。
参考：
[1].第8题-浏览器HTTP请求并发数和TCP连接的关系
