TCP和UDP的必知必会的点

前言P话

对于3年以下的程序员，每份工作的面试，有一个问题肯定事一定绕不过去的，那就是TCP和UDP，今天这篇文章跟大家分享一下关于Tcp和UDP的几个问题

问题一：UDP和TCP的简单介绍

UDP：是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个UDP数据报，并且组装称一份待发送的IP数据报
TCP：是面向流字符的，应用程序产生的全体数据与真正发送的单个IP数据报可能没什么联系

问题二：TCP通过哪些方式来保证可靠性？

1）应用数据被分割称TCP认为最适合发送的数据块
2）确认机制，发送报文后，等待确认
3）重发机制，没有收到确认，将重发数据段
4）保持它首部和数据的校验和，确认数据的准确性
5）排序，丢弃重复的，流量控制

问题三：TCP和UDP的概念相互的区别和优劣

1、TCP面向连接，UDP面向无连接
2、TCP面向字节流，UDP面向报文
3、TCP提供可靠传输服务（数据顺序，正确性），UDP传输不可靠
4、TCP协议传输速度慢，UDP协议传输速度块
5、TCP协议对系统资源要求多（头部开销大），UDP协议要求少

问题四：为什么要3次握手，4次挥手

1、3次握手：防止已经过期的连接请求报文突然又传送到服务器，因而产生错误
2、4次挥手：确保数据能够完成传输，但关闭连接时，当收到对方的FIN报文通知时，它i 仅仅表示对方没有数据发送给你了，但未你所有的数据都全部发送给对方了，所以你可以未必会马上关闭socket，也就是说你可能还需要发送一些数据给对方之后，再发送FIN报文给对方表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN保文多数情况下都是分开发送的

问题五：现代浏览器在与服务器简历一个TCP连接后是否会在一个HTTP请求后完成断开？什么情况下会断开？

在HTTP1.0中，一个服务器在发送完一个HTTP响应后，会断开TCp连接，但是这样每次请求都会重新建立和断开TCp连接，代价过大，虽然标准中没有设定，某些服务器对Connection：keep-alive的Header进行了支持，意思是说，完成这个HTTP请求之后，不要断开HTTP请求使用的TCp连接，这样的好处是连接可以被重新使用，之后发送HTTP请求的时候不需要重新建立TCp连接，以及如果维持连接，俺么SSL的开销也可以避免，两张图片是短时间内两次访问 https://www.github.com 的时间统计

头一次访问，有初始化连接和 SSL 开销

初始化连接和 SSL 开销消失了，说明使用的是同一个 TCP 连接

持久连接：既然维持TCP连接好处这么多，HTTP/1.1就把Connection头写进标准，并且默认开启持久连接，除非请求中写明：Connection：close，那么浏览器和服务器之间是会维持一段时间的TCP连接，不会一个请求结束就断掉
所以这个问题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求报头中声明connection：close才会在请求完成后关闭连接

问题六：一个 TCP 连接可以对应几个 HTTP 请求？

从上面那个问题的答案可以得出，如果维持连接，一个TCP连接是可以发送多个HTTP请求的

问题七：一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？

HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个HTTP请求从开始到结束的时间在同一个TCP连接里不能重叠
虽然 HTTP/1.1 规范中规定了 Pipelining 来试图解决这个问题，但是这个功能在浏览器中默认是关闭的。
先来看一下 Pipelining 是什么，RFC 2616 中规定了：

A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。
HTTP2 提供了 Multiplexing 多路传输特性，可以在一个 TCP 连接中同时完成多个 HTTP 请求
所以这个问题也有了答案：在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
那么在 HTTP/1.1 时代，浏览器是如何提高页面加载效率的呢？主要有下面两点：

维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求。
和服务器建立多个 TCP 连接。

问题八：浏览器对同一 Host 建立 TCP 连接到数量有没有限制？

假设我们还处在 HTTP/1.1 时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？肯定不能只开一个 TCP 连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个 TCP 连接发 HTTP 请求，那电脑或者服务器都可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 连接吧，你的电脑同意 NAT 也不一定会同意。

所以答案是：有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。

综合问题：收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。
如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。

参考文章：

作者：程序员之言
链接：https://www.jianshu.com/p/3ab1d942ef4e
来源：简书
。