计算机网路常见知识点汇总

有些图片是用ppt画的，不做标注。其他图片有些来自网络，有些来自书籍，我尽可能地标注，但是不清楚的暂时标注为网络，如果有标错、漏标或者是其他需要更改的，可以评论或者私信，我马上更改。
内容也有相当多是来自网络各种笔记整合，错误及其他需要更改之处也非常欢迎指出。
若造成什么不便，实在抱歉。

1.OSI七层模型、TCP/IP五层模型、TCP/IP四层模型

1.1 分层图

1.2 OSI七层模型各层的作用

1.2.1 应用层

	应用层位于OSI参考模型的第七层，其作用是通过应用程序间的交互来完成特定的网络应用。该层协议定义了应用
进程之间的交互规则，通过不同的应用层协议为不同的网络应用提供服务。例如域名系统DNS，支持万维网应用的HTTP
协议，电子邮件系统采用的SMTP协议等。在应用层交互的数据单元我们称之为报文。

1.2.2 表示层

	表示层的作用是使通信的应用程序能够解释交换数据的含义，其位于OSI参考模型的第六层，向上为应用层提供服
务，向下接收来自会话层的服务。该层提供的服务主要包括数据压缩，数据加密以及数据描述。这使得应用程序不必担
心在各台计算机中表示和存储的内部格式差异。

1.2.3 会话层

	会话层就是负责建立、管理和中止表示层实体之间的通信会话。该层提供了数据交换的定界和同步功能，包括了建
立检查点和恢复方案的方法。

1.2.4 传输层

	传输层的主要任务是为两台主机进程之间的通信提供服务。应用程序利用该服务传送应用层报文。该服务并不针对
某一特定的应用，多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用
的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别
交付给上面应用层的相应进程。

1.2.5 网络层

	在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的
任务就是选择合适的网间路由和交换节点，确保数据及时传送。在发送数据时，网络层把传输层产生的报文段或用户数
据报封装成分组和包进行传送。在TCP/IP体系结构中，由于网络层使用IP协议，因此分组也叫IP数据报，简称数据报。

1.2.6 数据链路层

	数据链路层通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的
链路层协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧，在两个相邻节点间的
链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）

1.2.7 物理层

	在物理层上所传送的数据单位是比特。
	物理层的作用是实现相邻节点之间比特流的透明传送，尽可能屏蔽掉具体传送介质和物理设备之间的差异，使其
上面的数据链路层不必考虑网络的具体传输介质是什么。“透明”传送比特流“表示经实际电路传送后的比特流没有发生
变化，对传送的比特流来说，这个电路好像是看不见的。

2.三次握手

推荐一篇博客，三次握手和四次挥手里面都写得很明白：
https://blog.youkuaiyun.com/qzcsu/article/details/72861891

2.1 三次握手过程

考烂的一道题，尽量说的充分一些。
（图片来源：https://blog.youkuaiyun.com/qzcsu/article/details/72861891）

SYN：TCP/IP建立连接时使用的握手信号。
ACK：确认字符，在数据通信传输中，接收站发给发送站的一种传输控制字符。他表示确认发来的数据已经接受无误

在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN-ACK应答表示接收到了
这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和
服务器之间传递。

2.2 为什么要三次握手

三次握手的目的时间里可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是
双方确认自己与对方的发送与接收是正常的

第一次握手：
	Client什么都不能确认
	Server确认了Client发送正常
第二次握手：
	Client确认了自己发送、接收都正常，Server发送、接收正常
	Server确认了自己接收正常，Client发送正常
第三次握手：
	Client确认了自己发送、接收都正常，Server发送、接收正常
	Server确认了自己发送、接收正常，Client发送、接收正常

连接建立

2.3 TCP为什么不是两次握手而是三次

如果仅两次连接可能出现一种情况：客户端发送完连接报文（第一次握手）后由于网络不好，延时很久后报文到达服务
端，服务端接收到报文后向客户端发起连接（第二次握手）。此时客户端会认定此报文为失效报文，但在两次握手情况
下服务端会认为已经建立起了连接，服务端会一直等待客户端发送数据，但因为客户端会认为服务端第二次握手的回复
是对失效请求的回复，不会去处理。这就造成了服务端一直等待客户端数据的情况，浪费资源。

3.四次挥手

推荐一篇博客，三次握手和四次挥手里面都写得很明白：
https://blog.youkuaiyun.com/qzcsu/article/details/72861891

3.1 四次挥手过程

（图片来源：https://blog.youkuaiyun.com/qzcsu/article/details/72861891）

断开一个TCP连接需要“四次挥手”
	客户端发送一个FIN，用来关闭客户端到服务器的数据传送
	服务器收到这个FIN，返回一个ACK，确认序号ack为收到的序号加1。
	服务器关闭与客户端的连接，发送一个FIN给客户端
	客户端返回ACK报文确认，并将确认序号设置为收到序号加1

3.2 为什么要四次挥手

	任何一方都可以在数据传送结束后发出连接释放的通知，，待对方确认后进入半关闭状态。当另一方也没有数据再
发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

3.3 为什么挥手是四次而不是三次

因为TCP是全双工通信的   
	（1）第一次挥手     
		因此当主动方发送断开连接的请求（即FIN报文）给被动方时，仅仅代表主动方不会再发送数据报文了，但主动
	方仍可以接收数据报文。   
	
	（2）第二次挥手     
		被动方此时有可能还有相应的数据报文需要发送，因此需要先发送ACK报文，告知主动方“我知道你想断开连接
	的请求了”。这样主动方便不会因为没有收到应答而继续发送断开连接的请求（即FIN报文）。   

	（3）第三次挥手    
		被动方在处理完数据报文后，便发送给主动方FIN报文；这样可以保证数据通信正常可靠地完成。发送完FIN报
	文后，被动方进入LAST_ACK阶段（超时等待）。   

	（4）第四挥手    
		如果主动方及时发送ACK报文进行连接中断的确认，这时被动方就直接释放连接，进入可用状态。

作者：魔方
链接：https://www.zhihu.com/question/63264012/answer/298264454
来源：知乎

3.4 为什么客户端最后还要等待2MSL

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，
我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是
服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会
重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认
报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中
不会出现旧连接的请求报文。

问题回答来自：
https://blog.youkuaiyun.com/qzcsu/article/details/72861891

3.5 CLOSE-WAIT和TIME-WAIT的状态和意义

	在服务器收到客户端关闭连接的请求并告诉客户端自己已经成功收到了该请求之后，服务器进入CLOSE-WAIT状态，
然而此时有可能服务端还有一些数据没有传输完成，因此不能立即关闭连接，而CLOSE-WAIT状态就是为了保证服务器
在关闭连接之前将待发送的数据发送完成。
	TIME-WAIT发生在第四次挥手，当客户端向服务端发送ACK确认报文后进入该状态，若取消该状态，即客户端在收到
服务端的FIN报文后立即关闭连接，此时服务端相应的端口并没有关闭，若客户端在相同的端口立即建立新的连接，则有
可能接收到上一次连接中残留的数据包，可能会导致不可预料的异常出现。除此之外，假设客户端最后一次发送端ACK包
在传输的过程中丢失了，由于TCP协议的超时重传机制，服务器将重发FIN报文，若客户端并没有维持TIME-WAIT状态而
直接关闭的话，当收到服务端重新发送的FIN包时，客户端就会用RST包来响应服务端，这将会使得对方认为是有错误发
生，然而其实只是正常的关闭连接过程，并没有出现异常情况。

4.TCP、UDP协议的区别

（1）TCP面向连接，通信前需要先建立连接；UDP面向无连接，通信前不需要连接
（2）TCP通过序号、重传、流量控制、拥塞控制实现可靠传输；UDP不保障可靠传输，尽最大努力交付
（3）TCP字节流传输，因此可以被分割在接收端重组；UDP面向数据报传输
（4）TCP传输效率相对UDP低
（5）TCP不提供广播或多播服务

5.在浏览器中输入url地址 到 显示主页的过程

推荐这个文章，东西很多，这是个相当复杂的过程：
https://www.cnblogs.com/Roni-i/p/9763045.html

6.用UDP实现可靠传输

（1）引入序列号，保证数据顺序
（2）引入确认应答，确保对端收到了数据
（3）引入超时重传，如果隔一段时间没有应答，重新发送数据
（4）引入窗口限制，要能根据网络传输情况调整窗口大小
...

是不是感觉类似于TCP？其实完全可以根据两者的不同来回答这个问题。

7.TCP怎么实现的可靠传输

和上面的问题有点重合。

（1）确认与重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传
（2）数据校验
（3）数据合理分片和排序
（4）流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的效率，防止包丢失
（5）拥塞控制：当网络拥塞时，减少数据的发送。

8.流量控制

8.1 什么是流量控制

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受

至于为什么要有流量控制，当然就是提高TCP的可靠性，并尽可能提高速度了

8.2 流量控制

这个知识点的内容都来自（《图解TCP_IP》）

	发送端根据自己的实际情况发送数据。但是，接收端可能收到的是一个毫无关系的数据包有可能会在处理其他问题
上花费一些时间。因此在为这个数据包做其他处理时会耗费一些时间，甚至在高负荷的情况下无法接收任何数据。如此
一来，如果接收端将本应该接收的数据丢弃的话，就又会触发重发机制，从而导致网络流量的无端浪费。
	为了防止这种现象的发生，TCP提供的一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是
所谓的流控制。它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这
个限制的数据。该大小限度就被称作窗口大小。
	TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己接收的缓冲区大小放入这个字段中通知给发送端。
这个字段的值越大，说明网络的吞吐量越高。
	不过，接收端的这个缓冲区一旦面临数据溢出时，窗口的大小的值也会随之被设置为一个更小的值通知给发送端，
从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。这也就形成一个完
整的TCP流控制（流量控制）

（图片来自：《图解TCP_IP》）

	如图所示，当接收端收到从3001号开始的数据段后其缓冲区即满，不得不暂时停止接收数据。之后，在收到发送
窗口更新通知后通信才得以继续执行。如果这个窗口的更新通知在传送途中丢失，可能会导致无法继续通信。为避免
此类问题的发生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口
大小信息。

8.3 流量控制其中的一些细节问题

感觉问的不是很多，不过是个很好的扩充问题

（内容来自：https://www.cnblogs.com/ppzhang/p/10506237.html）
非常推荐去看上面的这篇文章！

8.3.1 窗口探测

正如上面的示例所说，这个机制是为了防止数据丢失导致的无法通信。可以理解为死锁问题：

	1.B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400的报文
段，然而这个报文段在传送过程中丢失了。
	2.A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据，如果没有其他措施，这种相互等待的
死锁局面将一直持续下去。

问题解决：

　	1.TCP为每一个连接设有一个持续计时器。

　	2.只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。

　　3.若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测
　报文时给出了现在的窗口值。

　　4.如果窗口值仍然是零，那么收到这个报文段的一方就重新设置持续计时器。

　　5.如果窗口不是零，那么死锁的僵局就可以打破了。

8.3.2 糊涂窗口

问题描述：

　1.TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取为1个字节（这样就使接收缓存空间仅
腾出1个字节）

　2.然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报是40字节长）。

　3.接收方发回确认，仍然将窗口设置为1个字节。

　4.这样进行下去，使网络的效率很低。

解决：

　1.让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半
空闲的空间。

　2.只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。

　3.此外。发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

	Nagle算法和解决糊涂窗口综合证配合使用，使得在发送方不发送很小的报文段的同时接收方也不要在缓存刚刚有了
一点小的空间就急忙把这个很小的窗口大小信息通知给对方。

至于什么是Nagle算法：

	1.若发送应用进程把要求发送的数据逐个地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面
到达的数据字节都缓存起来。

	2.当发送方收到第一个数据字节的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随
后到达的数据进行缓存，只有在收到对前一个报文段的确认后才继续发送下一个报文段。

　3.当数据到达较快而网络速率较慢时，用这养的方法可明显减少所用的网络带宽。

　4.Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文
段。这样就可以有效的提高网络的吞吐量。

9.拥塞控制

以下内容同样来自，写的真的很棒：
https://www.cnblogs.com/ppzhang/p/10506237.html

9.1 什么是拥塞控制

	拥塞控制就是防止过多的数据注入网络中，使得网络中的路由器或链路不致过载得一种机制。

9.2 常用的方法

（1）慢开始
（2）拥塞避免
（3）快重传
（4）快恢复

9.2.1 慢开始与拥塞避免

（1）发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口
（2）刚开始采用慢开始的策略，当主机开始发送数据时，为避免一下子将大量数据注入到网络，造成或增加
拥塞，选择发送一个数据段的试探报文
（3）当收到第一个报文的确认后，就发送两个数据段的报文
（4）若收到两个数据段的报文，再发送四个，按照指数递增
（5）一直到拥塞窗口的值达到设置的阈值，就改用拥塞避免的策略，不再按照指数递增，而是按照线性增长，
每次增加一个数据段
	也就是按照：
		（一个数据段的字节数/拥塞窗口（字节）） * 1个数据段字节数 比例放大
（6）当出现网络拥塞，比如丢包时，将慢开始门限设为原来的一半，然后将拥塞窗口设为1，再执行慢开始算法

可以看看下面这幅图
（图片来源：网络）

避免算法比例增长的放大比例：
（图片来自：《图解TCP_IP》）

至于何时执行慢开始还是拥塞避免算法：
（1）cwnd（拥塞窗口） < ssthresh（阈值）， 继续使用慢开始算法；
（2）cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
（3）cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；

9.2.2 快重传和快恢复

	快重传和快恢复是为了减少因为拥塞导致的数据包丢失带来的重传时间，机制是：
（1）接收方建立机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求
（2）一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立即重传该包
（3）此时发送方开始执行“快恢复”算法
	--慢开始门限减半
	--拥塞窗口设为慢开始门限减半后的数值
	--执行拥塞避免算法

（图片来源：网络）

10.IP地址和MAC地址的区别

内容来自博客：
https://blog.youkuaiyun.com/guoweimelon/article/details/50858597

1）对于网络上的某一设备，如一台计算机或一台路由器，其IP地址是基于网络拓扑设计出的，同一台设备或计算机上，
改动IP地址是很容易的（但必须唯一），而MAC则是生产厂商烧录好的，一般不能改动。我们可以根据需要给一台主机
指定任意的IP地址，如我们可以给局域网上的某台计算机分配IP地址为192.168.0.112 ，也可以将它改成
192.168.0.200。而任一网络设备（如网卡，路由器）一旦生产出来以后，其MAC地址不可由本地连接内的配置进行修
改。如果一个计算机的网卡坏了，在更换网卡之后，该计算机的MAC地址就变了。 

2）长度不同。IP地址为32位，MAC地址为48位。 

3）分配依据不同。IP地址的分配是基于网络拓扑，MAC地址的分配是基于制造商。 

4）寻址协议层不同。IP地址应用于OSI第三层，即网络层，而MAC地址应用在OSI第二层，即数据链路层。 数据链路层
协议可以使数据从一个节点传递到相同链路的另一个节点上（通过MAC地址），而网络层协议使数据可以从一个网络传
递到另一个网络上（ARP根据目的IP地址，找到中间节点的MAC地址，通过中间节点传送，从而最终到达目的网络）。

11.HTTP请求方法（HTTP/1.1）

（内容选自：《图解HTTP》）

11.1 GET 获取资源

	GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的
资源是文本，那就是保持原样返回；如果是像CGI那样的程序，则返回经过执行后的输出结果。

11.2 POST 传输实体主体

	POST方法用来传输实体的主题内容

11.3 PUT 传输文件

	PUT方法用来传输文件。就像FTP协议的文件上传一样，要求在请求报文中包含文件内容，然后保存到请求URI指定
的位置。
	但是，鉴于HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，因此一般的Web网站
不适用该方法。若配合Web应用程序的验证机制，或架构设计采用REST（表征状态转移）标准的同类Web网站，就可能会
开放使用PUT方法

11.4 HEAD 获得报文首部

	HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。

11.5 DELETE 删除文件

	DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。
	同样，HTTP/1.1的DELETE方法本身和PUT方法一样不带验证机制，所以一般的Web网站也不适用DELETE方法。当配
合Web应用程序的验证机制，或遵守REST标准时还是可能会开放使用的。

11.6 OPTIONS 询问支持的方法

	OPTIONS方法用来查询针对请求URI指定的资源支持的方法。

11.7 TRACE 追踪路径

	TRACE方法是让Web服务器端将之前的请求通信返回给客户端的方法

11.8 CONNECT 要求用隧道协议连接代理

	CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL和TLS协议把通信
内容加密后经网路隧道传输。

HTTP/1.1 和 HTTP/1.0支持的方法对比

（图片来源：《图解HTTP》）

12.Keep-Alive和非Keep-Alive区别，对服务器性能有影响吗

	在早期的HTTP/1.0中，浏览器每次发起HTTP请求都要与服务器创建一个新的TCP连接，服务器完成请求处理后立即
断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。然而创建和关闭连接的过程需要消耗资源和时间，为了减少
资源消耗，缩短响应时间，就需要重用连接。在HTTP/1.1版本中默认使用持久连接，在此之前的HTTP版本的默认连接都
是使用非持久连接。
	对于非Keep-Alive来说，必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和
服务器都要分配TCP的缓冲区和变量，这给服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计的客
户机请求。在Keep-Alive方式下，服务器在响应后保持该TCP连接打开，在同一个客户机与服务器之间的后续请求和响
应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个Web页面在从该服务器发送给同一个客户机时，可以在
单个持久TCP连接上进行。
	然而，Keep-Alive并不是没有缺点的，当长时间的保持TCP连接时容易导致系统资源被无效占用，若对
Keep-Alive模式配置不当，可能会比非Keep-Alive模式带来的损失更大。因此，需要正确的设置Keep-Alive timeout
参数，当TCP连接在传送完最后一个HTTP响应，该连接会保持keepalive_timeout秒，之后就开始关闭这个链接。

13.HTTP长连接短连接使用场景是什么

	长连接：
	多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。
	
	短连接：
	用户数目较多的Web网站的HTTP服务一般用短连接。例如京东、淘宝这样的大型网站。

14.GET和POST的区别

	1.get提交的数据会放在URL之后，并且请求参数会被完整的保留在浏览器的记录里，由于参数直接暴露在URL中，
可能会存在安全问题，因此往往用于获取资源信息。而post参数放在请求主体中，并且参数不会被保留，相比get方法，
post方法更加安全，主要用于修改服务器上的资源。
	2.get请求只支持URL编码，post请求支持多种编码。
	3.get只支持ASCII字符格式的参数，而post方法没有限制。
	4.get提交的数据大小有限制，而post方法提交的数据没有限制
	5.get方法需要使用Request.QueryString来获取变量的值，而post方式通过Request.Form来获取

15.HTTP与HTTPS

15.1 HTTP和HTTPS的区别

	1.HTTP协议以明文方式发送内容，数据都是未加密的，安全性较差。HTTPS数据传输过程中是加密的，安全性较
好。
	2.HTTP和HTTPS使用的是完全不同的连接方式，用到端口也不一样，前者是80端口，后者是443端口。
	3.HTTPS协议需要用到数字认证机构申请证书，一般需要用到一定的费用。
	4.HTTP页面响应比HTTPS快，主要因为HTTP使用三次握手建立连接，而HTTPS除了握手外，还需要经历一个SSL
协商过程。
	5.HTTPS其实就是构建在SSL之上的HTTP协议，要比HTTP更耗费资源。

15.2 HTTP和HTTPS的工作方式（建立连接的过程）

	HTTP：
	HTTP是一种简单的请求-响应协议，被用于在Web浏览器和网站服务器之间传递消息。HTTP使用TCP作为它的支撑
运输层协议。其默认工作在TCP协议80端口，HTTP客户机发起一个与服务器的TCP连接，一旦连接建立，浏览器和服务器
进程就可以通过套接字接口访问TCP。客户机从套接字接口发送HTTP请求报文和发送HTTP响应报文。其通信内容以明文
的方式发送，不通过任何的数据加密。当通话结束时，客户端与服务器关闭连接。

	HTTPS：
	HTTPS是以安全为目标的HTTP协议，在HTTP的基础上通过传输加密协议和身份认证的方式保证了传输过程的安全
性。其工作流程如下：
	（1）客户端发起一个HTTPS请求，并连接道服务器的443端口，发送的信息主要包括自身所支持的算法列表和密钥
长度等。
	（2）服务端将自身所支持的所有加密算法与客户端的算法列表进行对比并选择一种支持的加密算法，然后将它和
其他密钥组件一同发送给客户端。
	（3）服务器向客户端发送一个包含数字证书的报文，该数字证书中包含证书的办法机构、过期时间、服务端的公钥
等信息。
	（4）最后服务端发送一个完成报文通知客户端SSL的第一阶段已经协商完成。
	（5）SSL第一次协商完成后，客户端发送一个回应报文，报文中包含一个客户端生成的随机密码串，称为
pre_master_secre，并且该报文是经过证书中的公钥加密过的。
	（6）紧接着客户端会发送一个报文提示服务端在此之后的报文是采用pre_master_secre加密的。
	（7）客户端向服务端发送一个finish报文，这次握手包含第一次握手至今所有报文的整体校验值，最终协商是否
完成取决于服务端能否成功解密。
	（8）服务端同样发送与第（6）步中作用相同的报文，已让客户端进行确认，最后发送finish报文告诉客户端自己
能够正确解密报文。
	当服务端和客户端的finish报文交换完成之后，SSL连接就算建立完成了，之后就进行和HTTP相同的通信过程，唯
一不同的是在HTTPS通信过程中并不是采用明文运输，而是采用对称加密的方式，其中对称密钥已经在SSL的建立过程中
协商好了。

16.状态码

16.1 状态码分类

	HTTP状态码由三个十进制数字组成，第一个数字定义了状态码的类型。
	HTTP状态码总共有5种类型：
	1XX：指示信息--表示请求正在处理
	2XX：成功--表示请求已被成功处理完毕
	3XX：重定向--要完成的请求需要进行附加操作
	4XX：客户端错误--请求有语法错误或者请求无法实现，服务器无法处理请求
	5XX：服务器端错误--服务器处理请求出现错误

16.2 常见状态码

200 OK

	请求成功。请求所希望的响应头或数据体将随此响应返回。

301 Moved Permanently

	永久移动。请求的资源已被永久地移动到新URI，返回信息会包含新的URI，浏览器会自动定向到新URI

302 Found

	临时移动。与301类似，但资源只是临时被移动，客户端应继续使用原有URI

303 See Other

	查看其他地址。与301类似，使用GET或POST请求查看。

304 Not Modified

	未修改。如果客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求
的条件）并没有改变，则服务器应当返回这个状态码。

400 Bad Request

	客户端请求的语法错误，服务器无法理解；请求的参数有误。

401 Unauthorized

	当前请求需要用户验证。

403 Forbidden

	服务器已经理解请求，但是拒绝执行它。

404 Not Found

	请求失败，请求所希望得到资源未被在服务器上发现

500 Internal Server Error

	服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。

503 Service Unavailable

	由于临时的服务器维护或者过载，服务器当前无法处理请求，一段时间后可能恢复正常。

更新情况

东西有点多，慢慢更新，错了再改，少了补充

	2021.1.23 
	模型、三次握手、四次挥手、TCP和UDP区别、浏览器种输入url地址到主页显示的过程（只有链接）、
用UDP实现可靠传输

	2021.1.26
	IP地址和MAC地址的区别，TCP如何实现的可靠传输，流量控制，拥塞控制。

	2021.1.28
	HTTP请求方法。

	2021.2.25
	OSI七层模型的各层介绍，Keep-Alive和非Keep-Alive，长短连接使用场景，GET和POSt区别，HTTP与HTTPS、
状态码，CLOSE-WAIT和TIME-WAIT的状态和意义。