TCP/UDP/HTTP/HTTPS

一、TCP和UDP的区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接（如送快递，不管你在不在，先送过去）。
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。UDP尽最大努力交付，即不保证可靠交付。
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流。UDP是面向报文的，所谓面向报文，是指面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文，因此能够明确区分两个数据包，避免粘包问题。。UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等） 。
4、每一条TCP连接只能是点到点的。UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节。
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。
7、应用场景，对准确性要求高，对效率速度要求低的可以选择TCP（QQ文件下载）。相反，对效率速度要求高，对准确性要求较低的选择UDP（如实时视频会议、QQ会话）

二、TCP三次握手和四次挥手

第一次握手：

建立连接时，客户端发送syn包到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：请求建立连接，seq（序列号）=x（x是客户端产生的随机数）。seq自己端发送每次+1。

第二次握手：

服务器收到syn包后，同时自己也发送一个SYN包，SYN=1请求建立连接，ACK=1表示确认收到之前客户端发来的信号。seq=y（y是服务端产生的随机数），ack=x+1（当ACK=1时，该值才有意义，表示确认收到客户端发来的信号，其中x+1是客户端发来是seq然后再+1）。此时服务器进入SYN_RECV状态；

第三次握手：

客户端收到服务器的包后，向服务端发送ACK=1表示确认收到服务端发来的信号，序列化seq=x+1（第一次客户端产生的随机数+1），ack=y+1（当ACK=1时，该值才有意义，表示确认收到服务端发来的信号，其中y+1是服务端发来的seq然后再+1）。此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1（请求断开连接），其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）服务器收到连接释放报文，发出确认报文，ACK=1（确认收到客户端发来的信号），ack=u+1（值就是客户端发来的seq然后再+1），并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接断开连接请求报文，FIN=1（请求断开连接），ACK=1（确认收到客户端发来的信号），ack=u+1（值就是客户端发来的seq然后再+1），由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w（服务端自己的序列化），此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器断开连接的报文后，必须发出确认，ACK=1（确认收到服务端信号），ack=w+1（服务端刚发来的序列化seq再加1），而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

三、常见面试题

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了（防止数据丢失），我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题2】为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题3】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

四、HTTP状态码

五、HTTP和HTTPS的区别

（1） HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
（2）HTTP 是不安全的，而 HTTPS 是安全的
（3）HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
（4）在 OSI 网络模型中，HTTPS的加密是在传输层完成的,因为SSL是位于传输层的，TLS的前身是SSL（加密体系），所以同理。
（5）HTTP无需认证证书,而https需要认证证书

六、HTTPS是如何保证安全的？

每当我们讨论到信息安全的时候，我们最长接触到的信息加密传输的方式莫过于 HTTPS 了，当我们浏览器地址栏闪现出绿色时，就代表着这个网站支持 HTTPS 的加密信息传输方式，并且你与它的连接确实被加密了。但是 HTTPS 并不是一个单一的东西，它只是我们常见的 HTTP 协议和某个加密协议的一个混合，这个加密协议通常会是 TLS。那么 HTTPS 为什么安全呢？其实我们需要先考虑 HTTP 为什么不安全。

假设你坐在一个教室里，你现在非常想把某个信息传递给教室里的另一个人，一般来说，会选择，传纸条。传纸条这个比喻其实非常正确，这就是互联网的一个基础协议 TCP/IP 协议基本的工作模式。而通常，HTTP 协议的数据是使用 TCP/IP 协议进行发送的。HTTP 指的是你在纸条上写明你要传送的目的地是哪个同学的坐位，然后再是要传递的内容。途径的同学拿到纸条后根据纸条上显示的地址依次传过去就好了。这样要面临的第一个问题就是：途径的同学可以完全知道你写了什么。

这就是 HTTP 面临的第一个问题，这个问题通常被叫做 “窃听” 或者 “嗅探” ，指的是和你在同一个网络下或者是途径的路由上的攻击者可以偷窥到你传输的内容。这是 HTTPS 要解决的第一个问题。这种问题通常是通过“加密”来解决的。从非常原始的角度来考虑，其实就是双方约定一个暗号。用什么字母去替代什么字母之类的。不过考虑到互联网每天有无数信息需要加密，这种原始的加密方法似乎不太适合。不过实际上方法也差不多，一般是采用一种叫做 AES 的算法来解决的。这种算法需要一个 密钥 key 来加密整个信息，加密和解密所需要使用的 key 是一样的，所以这种加密一般也被称为“对称加密”。AES 在数学上保证了，只要你使用的 key 足够足够足够足够的长，破解是几乎不可能的。

我们先假设这种破解确实是不可能的，而且目前也确实没有对 AES 本身能发动起有效的攻击的案例出现。

我们再回到这个教室，你接着要传小纸条，你把地址写上后，把要传输的内容用 AES 蹭蹭蹭加密了起来。刚准备传，问题来了。AES 不是有一个 key 吗？key 怎么给目的地啊？如果我把密钥直接写在纸条上，那么中间的人不依然可以解密吗？在现实中你可以通过一些其它方法来把密钥安全传输给目的地而不被其他人看见，但是在互联网上，要想这么做难度就很大了，毕竟传输终究要经过这些路由，所以要做加密，还得找一个更复杂的数学方法。

于是聪明的人们发明了一种更复杂的加密算法——非对称加密。这种加密或许理解起来比较困难，这种加密指的是可以生成一对密钥 (k1, k2)。凡是 k1 加密的数据，k1 自身不能解密，而需要 k2 才能解密；凡是 k2 加密的数据，k2 不能解密，需要 k1 才能解密。这种算法事实上有很多，常用的是 RSA，其基于的数学原理是两个大素数的乘积很容易算，而拿到这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因数确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位这么大），就算是超级计算机解密也需要非常长的时间。

现在利用这种非对称加密的方法，我们来设想一个场景。你继续想要传纸条，但是传纸条之前你先准备把接下来通讯的对称加密密钥给传输过去。于是你用 RSA 技术生成了一对 k1、k2，你把 k1 用明文发送了出去，路经有人或许会截取，但是没有用，k1 加密的数据需要用 k2 才能解密。而此时，k2 在你自己的手里。k1 送达目的地后，目的地的人会去准备一个接下来用于对称加密传输的密钥 key，然后用收到的 k1 把 key 加密了，把加密好的数据传回来。路上的人就算截取到了，也解密不出 key。等到了你自己手上，你用手上的 k2 把用 k1 加密的 key 解出来，现在全教室就只有你和你的目的地拥有 key，你们就可以用 AES 算法进行对称加密的传输啦！这时候你和目的地的通讯将无法再被任何人窃听！

当然，这时候你可能会问两个问题。
既然 非对称加密 可以那么安全，为什么我们不直接用它来加密信息，而是去加密 对称加密 的密钥呢？
这是因为 非对称加密 的密码对生成和加密的消耗时间比较长，为了节省双方的计算时间，通常只用它来交换密钥，而非直接用来传输数据。
使用 非对称加密 是完全安全的吗？

听起来确实是挺安全的，但实际上，还有一种更恶劣的攻击是这种方法无法防范的，这就是传说中的“中间人攻击”。我们继续让你坐在教室里传小纸条。现在你和目的地上途径一个中间人，他有意想要知道你们的消息。由于这个描述比较复杂，我们将你称为 A，你的目的地称为 B，而中间人称为 M。当你要和 B 完成第一次密钥交换的时候，途径了 M。M 知道你要进行密钥交换了，它把小纸条扣了下来，假装自己是 B，伪造了一个 key ，然后用你发来的 k1 加密了 key 发还给你，你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。同时 M 和 B 完成一次密钥交换，让 B 误以为和你完成了密钥交换。现在，由 A -> B完整的加密，变成了 A（加密连接1） -> M（明文）->B（加密连接2）的情况了。这时候 M 依然可以知道 A 和 B 传输中的全部信息。

对于这种事，我们似乎很难找到一个解决方法来解决这个问题，除非我们能从源头保证，你密钥交换的对象是安全的。这时候我们就要认识互联网 HTTPS 和你传纸条的微妙区别了。你传纸条时，你和你的目的地的关系几乎是对等的。而你访问网站时，你访问的对象通常是一个比较大的服务供应商，他们有充沛的资源，也许可以证明他们的合法性。

这时候我们会引入一个第三方叫做 CA。CA 是一些非常权威的专门用于认证一个网站合法性的组织。服务商可以向他们申请一个证书，使得他们建立安全连接时可以带上 CA 的签名。而 CA 的安全性由操作系统或浏览器来认证。你的 Windows、Mac、Linux、Chrome、Safari 等会在安装时带上一个他们认为安全的 CA 证书列表。如果和你建立安全连接的人带着这些人的签名，那么认为这个安全连接是安全的，没有遭到中间人攻击。

CA 证书通常情况下是安全的。因为一旦某个 CA 颁发出的某个证书被用于了非法用途，浏览器和操作系统一般会通过更新将整个 CA 颁发过的全部证书全部视为不安全。这使得 CA 通常在颁发证书时是比较小心的。

所以通过 对称加密 + 非对称加密 + CA认证 这三个技术混合在一起，才使得 HTTP 的后面加上了一个 S —— Security。实际上 HTTPS 的协议比我这里描述的更复杂一些，我这里说的主要是基本的实现原理。因为其中任何一环稍有闪失，就会使得整个加密都将变得不安全。这也是为什么 HTTPS 的加密协议从SSL 1.0 升级到 SSL 3.0 再被 TLS 1.0 现在被 TLS 1.2 取代，其背后都是一环环细节上的修改，以防任何地方的闪失。

但即使如此，你的 HTTPS 尽可能的保证了你传输的安全，但这种安全也不是绝对的。比如 CA 证书出了问题被用于了中间人攻击，在短期内，你的安全将会陷入直接的麻烦直到浏览器或操作系统重新更新了你的 CA 列表或者你手动调整了这个列表。但大多情况下不必杞人忧天，它基本上是安全的。

转载自> https://www.jianshu.com/p/b894a7e1c779