计算机网络学习 | 青训营笔记

这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记.计算机网络学习

（1）Http和Https的区别

HTTP：位于TCP/IP四层网络模型的应用层，也叫超文本传输协议。用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTPS:是以安全为目标的HTTP协议加强版。HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

区别：

1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

2、http是运行在TCP之上，连接简单，是无状态的、信息是明文传输，https是运行在SSL之上，信息是经过加密的。

（无状态：指协议对于交互性场景没有记忆能力。比如一个html网页，每一次请求独立，无论第一次、第二次结果都是同一个页面）

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

什么是SSL

    SSL 是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。
    为啥要发明 SSL 这个协议？因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。
    到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。所以这两者其实就是同一种协议，只不过是在不同阶段的不同称呼。
    
    SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：
SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

对称秘钥加密和非对称秘钥加密

对称密钥加密，又称私钥加密，即信息的发送方和接收方用同一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥管理困难。
非对称密钥加密，又称公钥加密，它需要使用一对密钥来分别完成加密和解密操作，一个公开发布，即公开密钥，另一个由用户自己秘密保存，即私用密钥。信息发送者用公开密钥去加密，而信息接收者则用私用密钥去解密。从功能角度而言非对称加密比对称加密功能强大，但加密和解密速度却比对称密钥加密慢得多。

SSL基本原理

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密，但是这里有两个问题：
（1）、如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。
（2）、公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
​
因此，SSL/TLS协议的基本过程是这样的：
1、客户端向服务器端索要并验证公钥。
2、双方协商生成“对话密钥”。
3、双方采用“对话密钥”进行加密通信。

Https工作原理

1、客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的443端口。
2、服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。
3、传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构、证书版本、序列号、签名算法标识符、签发⼈姓名、有效期、公钥信息等并附有CA的签名
4、客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
5、传送加密信息
这部分传送的是用证书加密后的随机值(私钥)，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6、服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密
7、传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

https工作过程

1. 客户端请求服务端的证书
2. 服务端选一套加密算法以及自己的身份信息以证书的形式发给客户端。证书包含（服务器信息、加密公钥、证书签发机构）
3. 客户端收到证书，验证证书合法性、生成对称秘钥用公钥加密。
4. 服务端解析出对称秘钥并存储
5. 客户端使用对称秘钥加密数据发送
6. 服务端使用对称秘钥解密数据，并把响应数据用对称加密

（2）TCP三次握手和四次挥手详解

SYN：表示同步序列编号(Synchronize Sequence Numbers)是否有效。该标志仅在三次握手建立TCP连接时有效。SYN=1说明这是一个请求建立链接或同意建立链接的报文。

ACK：确认标记

FIN：结束标记

seq：序号。代表请求方将发送的数据的第一个字节编号

ack：返回确认号。代表接收方接收到数据后（也就是前面的seq），希望对方下一次传输数据的第一个字节编号。

三次握手：

第一次握手：客户端给服务端发送一个请求链接的报文段，因为是请求连接所以SYN位设置为1，序列号seq设置为某一值，假设为x,发送出去客户端进入SYN_SEND状态，等待服务器的确认。
​
第二次握手：服务端收到客户端的SYN报文段，需要对这个请求报文段进行确认，设置确认号ack为x+1。同时自己还要发送建立链接SYN请求，seq设置为y。所以报文段中SYN和ACK都为1，ack=x+1，seq=y,一并发给客户端，此时服务器进入SYN_RECV状态。
​
第三次握手：客户端收到服务端返回的请求确认后。需要对这个确认报文段进行确认，设置确认号ack为y+1。所以这个报文段ACK=1  ack=y+1，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
​
客户端状态：SYN_SENDE   ESTABLISHED  
服务器端状态：SYN_RECV   ESTABLISHED

四次挥手：

可以是任何一端想结束会话断开链接。
​
第一次挥手：主机1向主机2发送一个断开连接报文，这个报文段断开标记FIN设置为1，假设设置序列号seq=u。之后主机1进入FIN_WAIT1状态；表示主机1没有数据要发送给主机2了
​
第二次挥手:主机2收到主机1发送的FIN报文。向主机1回复一个ACK确认报文段。确认号ack=u+1、序列号seq设置为v。主机2进入CLOSE_WAIT。意思我知道你说完了但我可能还有话说。报文到达主机1，主机1进入FIN_WAIT2。
​
第三次挥手：主机2向主机1发送断开连接报文。断开连接位FIN=1 seq设置为w，同时他也是一个确认报文段所以ACK=1，确认号ack=u+1。此时主机2进入LSAT_ACK。意思是我该说的都说了，我们可以断开了。
​
第四次挥手：主机1收到主机2发送的FIN报文段。向主机2发送确认报文段 ACK=1，确认号ack=w+1，序列号seq=u+1。然后主机1进入TIME_WAIT状态。主机2收到主机1的ACK报文段以后，就关闭链接。此时主机1在等待2MSL后没有收到回复，说明主机2已经正常关闭了，那么主机1也正常关闭。
​
主动方：FIN_WAIT1   FIN_WAIT2   TIM_WAIT
被动方：CLOSE_WAIT  LAST_ACK  CLOSED

为什么需要三次握手，两次不行吗？

弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。 因此，需要三次握手才能确认双方的接收与发送能力是否正常

两次不行，会发生已失效的连接请求报文段突然又传送到了服务端造成连接的错误
​
假设客户端，发送了连接1，连接2。连接2到达服务端，建立链接完成任务后TCP连接释放，连接1因为网络延迟在连接2释放之后才到服务器端，本来这是一个失效的链接请求，但服务端不知道，他向客户端发送确认报文段，并建立连接。此时会造成已失效的连接请求报文段突然又传送到了服务端，产生错误。

第三次握手失败了咋办

服务器都会有定时器，重发第二步的ACK+SYN报文，直至收到客户端的ACK成功。建立链接。

如果一直不成功，服务器会有一个超时设置，超时之后会给客户端发送RST（链接重置）报文。进入CLOSED状态。

挥手为什么需要四次？

TCP是一种全双工的通信模式。因此每个方向都必须单独进行关闭。

当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了。当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了。中间这两步不能同时发送所以需要4次挥手

三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

四次挥手释放连接时，等待2MSL的意义?

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

两个理由： 1、保证主机1发送的最后一个ACK报文段能够到达服务端。这个ACK报文段有可能丢失，使得处于LAST-ACK状态的主机2收不到对已发送的FIN+ACK报文段的确认，主机2超时重传FIN+ACK报文段，而主机1能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。

2、防止“已失效的连接请求报文段”出现在本连接中。客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

（3）七层协议每一层的作用，传输数据包的单位

	作用	单位	设备
应用层	直接为用户的应用程序提供服务	应用层传输单元
表示层	数据格式装换，数据加密与解密等	表示层传输单元
会话层	控制应用程序之间会话能力；如不同软件数据分发给不同软件。	会话层传输单元
传输层	提供端对端的通信服务。TCP/UDP	报文段
网络层	通过路由选择算法选择路由最佳路径。规划IP地址。拥塞控制	IP数据报、分组	路由器
数据链路层	组帧、差错控制 与 流量控制 以及MAC寻址	帧	网桥、交换机
物理层	使用光纤、双绞线这些物理传输介质实现比特流的传输	比特	光纤、双绞线

（4)tcp和udp的区别，各自的使用场景，tcp有什么特点？udp有什么特点？

两者都是传输层协议。

TCP（Transmission Control Protocol），传输控制协议

UDP（User Datagram Protocol），用户数据报协议

特点	TCP	UDP
连接性	面向连接	面向非连接
可靠性	可靠	不可靠
	保证质量，不保证速度	保证速度，不保证质量
	容易阻塞	容易丢包
	数据有序	不保证有序
	面向字节流	面向报文
	头部20字节	头部8字节

TCP面向链接，是一种可靠的协议。在基于 TCP 进行通信时，通信双方需要先建立一个 TCP 连接，建立连接需要经过三次握手，握手成功才可以进行通信

UDP 是一种面向无连接，在通信过程中，它并不像 TCP 那样需要先建立一个连接，只要（目的地址，端口号，源地址，端口号）确定了，就可以直接发送数据，并且不需要确保接收端一定能收到或收到完整的数据。

使用场景

TCP（对数据传输可靠性要求比较高的）： 文件传输

UDP（对丢包不敏感，不只是一对一，也可以是广播或者多播）：直播、视频聊天、实时游戏

TCP可靠性原理

1、采用三次握手来建立TCP连接，四次挥手来释放TCP连接，从而保证建立的传输信道是可靠的。

2、TCP采用了连续ARQ协议（停等协议、回退n帧协议、选择重传）来进行流量控制。

3、TCP报头中有检验码，对报文进行检查，确保数据没有损坏，保证数据传输正确性。

4、TCP使用慢开始、拥塞避免、快重传和快恢复来进行拥塞控制，避免网络拥塞。

TCP 和 UDP 分别对应的常见应用层协议有哪些？

1. TCP 对应的应用层协议

0. FTP：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。
1. Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是-纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。
2. SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。
3. POP3：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163 邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
4. HTTP：从 Web 服务器传输超文本到本地浏览器的传送协议。

2. UDP 对应的应用层协议

0. DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。
1. SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
2. TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

TCP粘包的原因和解决方法

原因：

1、TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；
2、从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。
​
基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

解决：

1、特殊字符控制；
2、在包头首都添加数据包的长度。

UDP如何实现可靠传输

最简单的方式是在应用层模仿传输层TCP的可靠性传输。

• 1、添加seq/ack确认机制，确保数据发送到对端
• 2、添加发送和接收缓冲区，添加超时重传机制。
• 3、添加拥塞控制机制。

（5）http1.0 http1.1 http2.0的区别

Http协议适用于TCP/IP四层网络模型的应用层。

Http也叫超文本传送协议。被用于从WWW服务器传输超文本到本地浏览器。

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上。

HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。

SPDY: 2012年google提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性。

HTTP2.0 相比于之前的 HTTP1.1 在性能上大幅度提升。

Http1.0 和 Http1.1的区别

1、长连接。
        在HTTP 1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，开销太大。
        HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。HTTP1.1中默认开启Connection： keep-alive。
​
2、Host头处理。
        HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
        HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
​
3、新增错误状态响应码。
        HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
        
4、带宽优化
        HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。
        HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content）

SPDY

1、降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
​
2、请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
​
3、header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
​
4、基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
​
5、服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

HTTP2.0可以说是SPDY的升级版

0. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
1. HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE

HTTP2.0 与 Http1.1

1、二进制分帧。HTTP 2.0 会将所有传输信息，分割为更小的消息和帧，并对它们，采用二进制格式的编码将其封装。
​
2、多路复用（MultiPlexing）。http2.0完全摒弃http1.1半双工通信的方式，实现了全双工通信，具体表现为：浏览器针对同一个域名的资源，只建立一个tcp连接通道，所有的针对这个域名的请求全部在这个通道中完成并且引入了流机制，这条通道可以同时处理多个request，这不同于http1.1的长连接。http2的多路复用，对于request的响应并不会因为上一个request的响应未完成而阻塞。在降低了延迟同时提高了带宽的利用率。
​
3、头压缩，HTTP 2.0 会对HTTP的头进行一定的压缩，将原来每次都要携带的大量 key value在两端建立一个索引表，对相同的头只发送索引表中的索引。
​
4、服务端推送（server push）。服务端响应客户端第一个请求的时候会吧这个页面的很多附加资源，一起发送到客户端，省去了客户端重复请求的步骤。
例如我的网页有一个sytle.css的请求，服务端不仅发送sytle.css数据，还会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

（6）常见的Http状态码有哪些？

2XX：请求正常处理完毕。

200：请求被正常处理

204：请求被受理但没有资源可以返回 3XX：重定向

301：永久性重定向 ：表示旧地址的资源已经这个资源不可访问了，浏览器在抓取新内容的同时会将 网址 变为为新网址。

302：临时重定向 ：表示旧地址的资源还可以访问，浏览器会抓取新内容 网址 保存为旧网址

303：允许重定向时改变请求方法

什么是重定向：（客户端和服务器端 最少两次请求）服务器响应第一次请求的时候，让浏览器再向另一个URL发起请求，从而达到转发目的。
OneServlet工作完毕后，将TwoServlet地址写入到响应头location属性中，服务器将重定向的状态码写入到状态行。在浏览器接收到响应包之后，会读取到重定向状态码。此时根据响应头中location属性地址（URL）向服务器发起第二次请求，访问TwoServlet。
​
ps：请求转发：（无论多少次请求，浏览器只发送一次请求）在服务器内部的资源跳转方式
OneServlet工作完毕后，在服务器内部通过oneServlet的请求对象代替浏览器向服务器发送请求，申请调用TwoServlet。服务器内部自动调用TwoServlet来完成剩余工作。
​
通俗的例子：
重定向：A 找 B 借钱，B 说没有，让 A 去找 C 借
请求转发：A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A
​
301和302本来在规范中是不允许重定向时改变请求方法（将POST改为GET），但是许多浏览器却允许重定向时改变请求方法（这是一种不规范的实现）。303的出现正是为了给上面的301，302这种行为作出个规范（将错就错吧），也就是允许重定向时改变请求方法。

304：发送附带条件的请求时，条件不满足时返回，与重定向无关

4XX：客户端错误

400：请求参数有误，服务器无法识别

401：请求需要有通过HTTP认证的认证信息

403：请求的对应资源被服务器拒绝了

404：url错误，服务器无法找到对应资源

405：服务器不允许使用请求行中所指定的方法。（指定只能post请求，确使用的get请求方法)

5XX：服务器错误

500：服务器内部错误

503：服务器正忙变

（7）对称加密和非对称加密的区别，都有哪几种加密算法举例说明

对称密钥加密，又称私钥加密，即信息的发送方和接收方用同一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，但密钥管理困难（即如何安全的吧秘钥发给对方）。 ​ 非对称密钥加密，又称公钥加密，它需要使用一对密钥来分别完成加密和解密操作，一个公开发布，即公开密钥，另一个由用户自己秘密保存，即私用密钥。信息发送者用公开密钥去加密，而信息接收者则用私用密钥去解密。

对称加密算法：AES、DES、3DES、RC4、RC5

非对称加密算法： RSA、ECC（椭圆曲线算法）

（8）在浏览器输入网址出来网站的首页，详细过程

0. 浏览器获取url，根据DNS解析获得网址的对应IP地址

   具体：浏览器缓存 -- > 操作系统缓存 --> 本地路由器缓存 逐层进行搜索，如果任意一层缓存里面有，就返回查到的ip地址。如果本机 DNS服务器没有结果，会发送一个递归查询请求，一层一层的向高层DNS服务器做查询。直至起始授权机构。吧结果返回。

1. 浏览器依靠查到的IP地址，通过TCP三次握手来建立链接。

2. 浏览器向服务器发送http请求报文。

3. 服务器处理请求，并返回一个响应报文 给浏览器。

4. 浏览器收到响应对象，读取内容，解析html，生成DOM树，CSS样式树。

5. 绘制渲染树，计算并布局，浏览器调用渲染引擎进行绘制页面并显示。

（9）http长连接和短链接的区别，各自的使用场景

HTTP协议是基于请求/响应的。只要服务器端回复了响应本次HTTP就结束了。长短连接不是说的HTTP而是TCP。

在 HTTP/1.0 中默认使用短连接。也就是说，每次请求都要重新建立一次连接，由于http又是建立在TCP连接之上的，所以每一次请求都需要三次握手，握手成功才可以。非常消耗资源

从 HTTP/1.1 起，默认使用长连接，当一次连接成功后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

长连接场景：适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏等。

短连接场景：像京东,淘宝这些大型的网站,随时随刻有成千上万的用户对服务端发送请求,一般使用短连接,因为如果用长连接的话,用户越来越多，服务器扛不住。

10）cookie和session的区别 和Token

1、cookie数据在浏览器上（缓存、硬盘）。session在服务器上（内存、文件、数据库）。

2、一个cookie对象只能存储一个共享数据，一个session对象可以存储任意个更共享数据。

3、Cookie 存储的共享数据类型只能是String ，session可以是任意类型

4、销毁时机：

cookie：默认情况下Cookie对象存放在浏览器的缓存中。因此只要浏览器关闭，Cookie对象就被销毁掉。
       在手动设置情况下，可以要求浏览器将接收的Cookie，存放在客户端计算机上硬盘上，同时需要指定Cookie在硬盘上存活时间。在存活时间范围内，关闭浏览器，关闭客户端计算机，关闭服务器，都不会导致Cookie，被销毁。在存活时间到达时，Cookie自动从硬盘上被删除。例如记住密码就是使用永久cookie写在客户端电脑。下次登录时，自动将cookie信息发给服务端。
​
session： session数据是存放在服务器上的，sessionId是存放在浏览器的cookie上，并且与session关联的Cookie只能存放在浏览器缓存中。在浏览器关闭时，意味着用户与他的HttpSession关系被切断，由于服务器无法检测浏览器何时关闭，因此在浏览器关闭时并不会导致服务器将浏览器关联的HttpSession进行销毁，为了解决这个问题，服务器为每一个Session对象设置【空闲时间】，这个空闲时间默认30分钟，如果当前HttpSession对象空闲时间达到30分钟，此时服务器认为用户已经放弃了自己的HttpSession，此时服务器就会销毁掉这个HttpSession

Token

为什么要出现token：
    1、服务器给每个用户一个sessionId记录谁登录了，每个用户只需要记录一个session，而服务器需要记录所有人的sessionid，如果是大型网站，这就是几十上百万个。服务器压力太大。
    2、进行优化，设置服务器集群。那也不行啊，如果我第一次登录了A系统，我第二次登录在B系统了。怎么办？？？？复制？压力也不小。
    3、再优化，吧session存储在一个单独的地方，所有的机器都到这个地方来获取session。这样不用复制，但容易出现单点失败的可能性。单点也搞集群？不论如何session的存储对我们来说是一个大问题。
​
于是有人就提出了Token设想
sessionId是用来干啥的？不就是登录验证的吗。
    1、我们可以在用户登录的时候给他一个令牌（token），下次访问我的时候，吧token通过请求头带过来不就行了。（不过这和session本质没区别啊，而且任何人都可以仿照，也不安全）
    2、为了防止伪造，就加秘钥。登录之后给一个秘钥，通过加密算法，对数据进行加密（叫做签名）。这个秘钥别人不知道，就没法仿照了。
    3、吧数据和签名一起作为token，传给服务端。服务器使用同样的秘钥，对数据进行再一次相同的加密，通过比较两次签名，来判断是否登录。
    4、这样一来，我就不用记录了，用我cpu计算token的时间来换空间。

Token的优势：

0. 无状态，可扩展。无状态指只要登录了，无论第一次访问，第二次访问都是同一个资源。可扩展指：第一次登录A服务器分配token，你第二次登录B服务器，不影响。不像session需复制再查询，token只需要计算一下即可。
1. 安全。使用秘钥加密，更加安全。而且token是有时效的，一段时间后用户需要重新认证。
2. 多平台跨域。只要用户有一个通过验证的token。数据和资源能在任何域上被请求到。
3. 支持移动设备。

Session和Token区别

Session和Token都是用户身份验证的一种手段，都有过期时间限制但也有不同

1、Session是数据存放在服务端，sessionId存放在客户端。它采用空间换时间的策略。

2、token是存放在客户端，采用时间换空间策略。他是可扩展的，所以在分布式环境中应用广泛。