专栏总结1：基础网络相关

请不要付费，只是把历史笔记发布，包含专栏内容总结。

专栏总结1：基础网络相关
专栏总结2：数据结构和算法
专栏总结3：操作系统和计算机原理
专栏总结4：Linux和linux内核
专栏总结5：mysql相关
专栏总结6：redis相关

专栏总结7：中间件Nginx、消息队列
专栏总结java1：类型和String、反射
专栏总结java2：集合
专栏总结java3：类接口相关
专栏总结java4：异常
专栏总结java5：线程/多线程并发
专栏总结java6：jvm
专栏总结java7：jdk
专栏总结java8：Socket编程 nio
专栏总结java9：MyBatis+hibernate

专栏总结java10：Spring
专栏总结java11：Spring MVC
专栏总结java12：springboot
专栏总结java13：springcloud
专栏总结java14：dubbo

专栏总结：场景实践
专栏总结：架构设计总结

网络知识总结https://blog.csdn.net/hguisu/category_1122753.html?spm=1001.2014.3001.5482

一、网络模型

---

1、OSI七层模型都是什么

2、举例网络协议，都在哪个层

3、传输层与网络层在功能上的最大区别？

最大区别是传输层提供进程通信能力。从这个意义上讲，网络通信的最终地址就不仅仅是主机地址了，还包括可以描述进程的某种标识符。为此，TCP/IP协议提出了协议端口（protocol port，简称端口）的概念，用于标识通信的进程。 

二、TCP和UDP

---

1、TCP和UDP区别？

《TCP/IP第四层--传输层TCP和TPC数据报文详解》

一、TCP与UDP区别总结：
1、连接区别：TCP面向连接(TCP三次握手如打电话要先拨号那样建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、可靠性区别：TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
   TCP通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
3、时效性区别：UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。
4、交互区别：每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、消耗资源：TCP对系统资源要求较多，UDP对系统资源要求较少。

二、为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势，在越来越多场景下取代了TCP,如实时游戏。

（1）网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低，如果使用应用层重传，能够确保传输的可靠性。
（2）TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置的系统协议栈中，极难对其进行改进。
采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

2、TCP如何实现可靠连接

TCP是实现可靠连接的机制是：主要通过检验和、序列号、确认应答（ACK）、重发控制、连接管理、窗口控制等实现可靠性连接。

连接管理：建立连接的三次握手和断开连接的四次挥手。

数据分段：应用数据分割成TCP认为最适合发送的数据块。以段为单位发送数据包，在建立TCP连接的同时，两端协商发送数据包的单位，称为“最大消息长度”：MSS。 【TCP数据(MSS字节)】【TCP首部(20字节)】【IP首部(20字节)】。值得注意的是，MSS只能出现在SYN报文段中，若一方不接收来自另一方的MSS值，则MSS就定为536字节。一般来讲，在不出现分段的情况下，MSS值还是越大越好，这样可以提高网络的利用率。

校验和：  TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。(发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段)。

序列号：TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。 

确认应答：接收方收到报文就会确认（累积确认：对所有按序接收的数据的确认）。

重发控制：当TCP发出一个段后，它启动一个定时器，等待接收方确认收到这个报文段。如果不能及时收到一个确认ACK，将重发这个报文段。一旦开始重传，下一次等待的时间间隔指数增长，重发一定次数后还是收不到ACK信号，将强制终止连接。

流量控制：TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，就把窗口缩小，并把窗口window值告诉发送端（提示发送方降低发送的速率，防止包丢失）。

TCP使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制，随ACK报文发送)

拥塞控制：当网络拥塞时，减少数据的发送。发送端通过拥塞窗口主动控制传输流量。慢启动：防止双方通信刚开始就传送大量数据包，发送端拥塞窗口初始设置为1MSS，每接受一个ACK信号，窗口扩大为两倍。发送数据时，取拥塞窗口和滑动窗口的较小值。同时设定一个慢启动阈值，当拥塞窗口大小超过阈值时，改为线性增长，直到网络拥塞。拥塞时将慢启动阈值设置为当前窗口的的一半，并将拥塞窗口的值设置为1，然后再次重复操作。

3、为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

为什么上图中的主动端A在TIME-WAIT状态必须等待2个MSL时间呢？ 
第一，保证可靠的实现TCP全双工链接的终止：为了保证主动端A发送的最后一个ACK报文能够到达被动段B，确保被动端能进入CLOSED状态。

对照上图，在四次挥手协议中，当B向A发送Fin+Ack后，A就需要向B发送ACK+Seq报文，A这时候就处于TIME_WAIT 状态，但是这个报文ACK有可能会发送失败而丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样B就无法按照正常的步骤进入CLOSED状态。

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

假设在A的XXX1端口和B的80端口之间有一个TCP连接。我们关闭这个连接，过一段时间后在相同的IP地址和端口建立另一个连接。后一个链接成为前一个的化身。因为它们的IP地址和端口号都相同。TCP必须防止来自某一个连接的老的重复分组在连 接已经终止后再现，从而被误解成属于同一链接的某一个某一个新的化身。为做到这一点，TCP将不给处于TIME_WAIT状态的链接发起新的化身。既然 TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活msl秒即被丢弃，另一个方向上的应答最多存活msl秒也被丢弃。 通过实施这个规则，我们就能保证每成功建立一个TCP连接时。来自该链接先前化身的重复分组都已经在网络中消逝了。

什么是2MSL

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

3、Linux发现系统存在大量TIME_WAIT状态的连接，可以通过调整内核参数解决

发现系统存在大量TIME_WAIT状态的连接，可以通过调整内核参数解决：vi /etc/sysctl.conf 加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
 然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间
 

4、如果TCP突然接收方故障 会发生什么

1、发送方无法接收到ACK, 发生重传

2 、自己实现心跳检测的方法来确定对方是不是已经断开连接

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

ACK：用于对收到的数据进行确认，所确认的数据由确认序列号表示。
SYN：用作建立连接时的同步信号
FIN：表示后面没有数据需要发送，通常意昧着所建立的连接需要关闭了。

一个完整的三次握手也就是： 请求SYN---应答SYN+ACK--再次确认ACK。

对应的函数接口：
       

建立一个连接需要三次握手，而终止一个连接要经过四次握手，这是由TCP的半关闭(half-close)造成的，如图：

由于TCP连接是全双工的（即数据在两个方向上能同时传递，可以理解为两个方向相反的独立通道），因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。当一端收到一个 FIN只意味着这一方向上没有数据流动（例如服务端linux内核让read返回0来通知应用层客户端已经终止数据发送了），一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

如图：

过程如下：

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

6、为什么TCP建立连接协议是三次握手，而关闭连接却是四次握手呢？为什么不能用两次握手进行连接？

为什么TCP建立连接协议是三次握手

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

这是由TCP的半关闭(half-close)造成的

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
 

7、为什么不能改成两次握手？

有人会困惑为什么要进行三次握手呢（两次确认）？这主要是为了防止已失效的请求连接报文忽然又传送到了，从而产生错误。
假定A向B发送一个连接请求，由于一些原因，导致A发出的连接请求在一个网络节点逗留了比较多的时间。此时A会将此连接请求作为无效处理 又重新向B发起了一次新的连接请求，B正常收到此连接请求后建立了连接，数据传输完成后释放了连接。如果此时A发出的第一次请求又到达了B，B会以为A又发起了一次连接请求，如果是两次握手：此时连接就建立了，B会一直等待A发送数据，从而白白浪费B的资源。 如果是三次握手：由于A没有发起连接请求，也就不会理会B的连接响应，B没有收到A的确认连接，就会关闭掉本次连接。
 

8、TCP 报文头部的字段

我们通过 Wireshark 抓包：就分别看到五层数据：
第一行Frame 3339：物理层数据帧：线路83字节，实际捕获83字节
第二行Ethernet II：链路层网卡，以太网协议版本II，源地址：厂名_序号（网卡地址），目的：厂名_序号（网卡地址）
第三行Internet Protocol Version 4：网络层ip数据包，IPV4,源IP地址：10.44.13.7;目的IP是：10.171.8.154
第四行Transmission Control Protocol：传输层TCP数据包：源端口21000，目的端口：52529；Seq序列号：每发送一个RTP数据包，序列 号就加1；ACK是TCP数据包首部中的确认标志，对已接收到的TCP报文进行确认，其为  183589表示确认号有效;Len长度是17字节；
第五行data：数据

9、TCP的超时重传时间是如何计算的

TCP重传机制：

TCP协议是一种面向连接的可靠的传输层协议，它保证了数据的可靠传输，对于一些出错，超时丢包等问题TCP设计的超时与重传机制。其基本原理：在发送一个数据包（比如SYN）之后，就开启一个定时器，若是在一定时间内（RTO）没有收到发送数据包的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。

TCP重传机制的原因：

TCP 数据包在一个IP包中传输。IP包可能在网络中丢失。导致IP包丢失的原因可能有很多，比如IP包经过太多的路由器接力，达到hop limit；比如路由器太过拥挤，导致一些IP包被丢弃；再比如路由表(routing table)没有及时更新，导致IP包无法送达目的地

两种重新发送TCP片段的机制：

超时重新发送

我们之前已经简单介绍过重新发送的机制：当发送方送出一个TCP片段后，将开始计时，等待该TCP片段的ACK回复。如果接收方正确接收到符合次序的片段，接收方会利用ACK片段回复发送方。发送方得到ACK回复后，继续移动窗口，发送接下来的TCP片段。如果直到计时完成，发送方还是没有收到ACK回复，那么发送方推断之前发送的TCP片段丢失，因此重新发送之前的TCP片段。这个计时等待的时间叫做重新发送超时时间(RTO, retransmission timeout)。

RTO：沙漏中沙子的多少

发送方应该在等待多长时间之后重新发送呢？这是重新发送的核心问题。上述过程实际上有往返两个方向：

1. 发送片段从发送方到接收方的传输，2. ACK片段从接收方到发送方的传输。

整个过程实际耗费的时间称做往返时间(RTT, round trip time)。如果RTT是固定的，比如1秒，那么我们可以让RTO等于RTT。但实际上，RTT的上下浮动很大。比如某个时刻，网络中有许多交通，那么RTT就增加。在RTT浮动的情况下，如果我们设置了过小的RTO，那么TCP会等待很短的时间之后重新发送，而实际上之前发送的片段并没有丢失，只是传输速度比较慢而已，这样，网络中就被重复注入TCP片段，从而浪费网络传输资源。另一方面，如果RTO时间过长，那么当TCP片段已经实际丢失的情况下，发送方不能及时重新发送，会造成网络资源的闲置。所以，RTO必须符合当前网络的使用状况。网络状况越好，RTO应该越短；网络状况越差，RTO应该越长。

RTT: 往返时间

TCP协议通过统计RTT，来决定合理的RTO。发送方可以测量每一次TCP传输的RTT (从发送出数据片段开始，到接收到ACK片段为止)，这样的每次测量得到的往返时间，叫做采样RTT(srtt, sampling round trip time)。建立连接之后，每次的srtt作为采样样本，计算平均值(mean)和标准差(standard deviation)，并让RTO等于srtt平均值加上四倍的srtt标准差。

RTO = mean + 4 std

(上述算法有多个变种，根据平台不同有所变化)

平均值反映了平均意义上的RTT，平均往返时间越大，RTO越大。另一方面，标准差越大也会影响RTO。标准差代表了RTT样本的离散程度。如果RTT上下剧烈浮动，标准差比较大。RTT浮动大，说明当前网络状况相对不稳定。因此要设置更长的RTO，以应对不稳定的网络状况。

快速重新发送

我们刚才介绍了超时重新发送的机制：发送方送出一个TCP片段，然后开始等待并计时，如果RTO时间之后还没有收到ACK回复，发送方则重新发送。TCP协议有可能在计时完成之前启动重新发送，也就是利用快速重新发送(fast-retransmission)。快速发送机制如果被启动，将打断计时器的等待，直接重新发送TCP片段。

由于IP包的传输是无序的，所以接收方有可能先收到后发出的片段，也就是乱序(out-of-order)片段。乱序片段的序号并不等于最近发出的ACK回复号。已接收的文本流和乱序片段之间将出现空洞(hole)，也就是等待接收的空位。比如已经接收了正常片段5,6,7，此时又接收乱序片段9。这时片段8依然空缺，片段8的位置就是一个空洞。

补上空洞

TCP协议规定，当接收方收到乱序片段的时候，需要重复发送ACK。比如接收到乱序片段9的时候，接收方需要回复ACK。回复号为8 (7+1)。此后接收方如果继续收到乱序片段(序号不是8的片段)，将再次重复发送ACK=8。当发送方收到3个ACK=8的回复时，发送方推断片段8丢失。即使此时片段8的计时器还没有超时，发送方会打断计时，直接重新发送片段8，这就是快速重新发送机制(fast-retransmission)。

快速重新发送机制利用重复的ACK来提示空洞的存在。当重复次数达到阈值时，认为空洞对应的片段在网络中丢失。快速重新发送机制提高了检测丢失片段的效率，往往可以在超时之前探测到丢失片段，并重复发送丢失的片段。

10、SYN Flood的攻击原理

      在进行三次握手时，攻击软件向被攻击的服务器发送SYN连接请求（握手的第一步），但是这个地址是伪造的，如攻击软件随机伪造了51.133.163.104、65.158.99.152等等地址。服务器在收到连接请求时将标志位ACK和SYN置1发送给客户端（握手的第二步），但是这些客户端的IP地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。

       这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYN Flood攻击（SYN洪水攻击）

三、Http

---

1、HTTP封装格式

HTTP 请求由三部分组成：请求行、  请求头和请求正文。

请求行：请求方法 URI 协议/版本

请求头(Request Header)

 请求正文

2、HTTP状态码 含义，503 504,200

状态代码由 3 位数字组成， 表示请求是否被理解或被满足，状态描述给出了关于状态码的简短的文字描述。状态码的第一个数字定义了响应类别，后面两位数字没有具体分类。第一个数字有 5 种取值，如下所示。

1xx：指示信息——表示请求已经接受，继续处理
2xx：成功——表示请求已经被成功接收、理解、接受。
3xx：重定向——要完成请求必须进行更进一步的操作
4xx：客户端错误——客户端请求有错误或请求无法实现
5xx：服务器端错误——服务器未能实现合法的请求。
常见状态代码、状态描述、说明：
200 OK      //客户端请求成功

301 redirect: 301 代表永久性转移(Permanently Moved)，301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；比如旧的域名不用，跳转到新域名。

302 redirect: 302 代表暂时性转移(Temporarily Moved ) ，302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。比如旧的域名也保留使用，但同时使用新域名。

303：重定向，即从原url重定向到新的url。 例如php 的hear函数header（"localtion:/index.php"）

400 Bad Request  //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden  //服务器收到请求，但是拒绝提供服务，一般是服务器路径没有权限或者是其他权限相关问题
404 Not Found  //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误：一般来说，这个问题都会在服务器端的源代码出现错误时出现，比如出现死循环。

502 Bad Gateway//作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。比如LNMP ,php-fpm没有启动就会报502错误。

503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后可能恢复正常，比如java 容器部署war的时候，就出现503,
                                           或者是nginx处理的文件没有权限。

504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应，比如nginx和php-fpm， php设置sleep（200），就会收到504 Gateway Time-out。注意：某些代理服务器在DNS查询超时时会返回400或者500错误

3、GET POST区别

GET与POST方法有以下区别：

      1、  在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放在HTTP包的body中。

      2、 GET方式提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST则没有此限制。

      3、安全性问题。正如在（1）中提到，使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。

      4.、服务器取值方式不一样。GET方式取值，如php可以使用$_GET来取得变量的值，而POST方式通过$_POST来获取变量的值。
 

4、一个url从输入到访问经过了哪些过程：浏览器发起一个请求到收到响应中间经历了哪些过程？知道多少就说多少，越详细越好。

一次HTTP操作称为一个事务，其工作整个过程如下：

     1 ) 、地址解析，

     如用客户端浏览器请求这个页面：http://localhost.com:8080/index.htm

     从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
     协议名：http
     主机名：localhost.com
     端口：8080
     对象路径：/index.htm

      在这一步，需要域名系统DNS解析域名localhost.com,得主机的IP地址。

    2）、封装HTTP请求数据包

     把以上部分结合本机自己的信息，封装成一个HTTP请求数据包

     3）封装成TCP包，建立TCP连接（TCP的三次握手）

       在HTTP工作开始之前，客户机（Web浏览器）首先要通过网络与服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。这里是8080端口

     4）客户机发送请求命令

       建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可内容。

     5）服务器响应

     服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

        实体消息是服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

     6）服务器关闭TCP连接

     一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

    Connection:keep-alive

   TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
 

5、HTTP 1.1版本增加了哪些内容？

1、默认持久连接：HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
2、HTTP1.1在Request消息头里头多了一个Host域、

3、断点续传原理：HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。

6、有哪几种请求方式？get post 、put、delete。

在 HTTP 协议中，HTTP 请求可以使用多种请求方法，这些方法指明了要以何种方式来访问 Request-URI 所标识的资源。HTTP1.1 支持的请求方法如下表所示：

HTTP1.1 中的请求方式：
GET  ： 请求获取由 Request-URI 所标识的资源
POST  ：  请求服务器接收在请求中封装的实体，并将其作为由 Request-Line 中的 Request-URI 所标识的资源的一部分
HEAD   ： 请求获取由 Request-URI 所标识的资源的响应消息报头
PUT  ：  请求服务器存储一个资源，并用 Request-URI 作为其标识符

DELETE： 请求服务器删除由 Request-URI 所标识的资源
TRACE：请求服务器回送到的请求信息，主要用于测试或诊断
CONNECT  ：保留将来使用
OPTIONS： 请求查询服务器的性能，或者查询与资源相关的选项和需求
 

7、啥是无状态协议

http是无状态的协议，也是不安全的协议，

它的无状态是指对于事务处理没有记忆能力，缺少状态意味着后续的操作需要前面的信息。即同一个会话的连续两个请求互相不了解

解决办法：1，通过cookie解决，2，通过session会话保存。

8、对称加密和非对称加密。

   1)、对称加密（symmetrcic encryption）：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES，RC5，3DES等；

       对称加密主要问题是共享秘钥，除你的计算机（客户端）知道另外一台计算机（服务器）的私钥秘钥，否则无法对通信流进行加密解密。解决这个问题的方案非对称秘钥。

      2)、非对称加密：使用两个秘钥：公共秘钥和私有秘钥。私有秘钥由一方密码保存（一般是服务器保存），另一方任何人都可以获得公共秘钥。

      这种密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
 

9、 https 是如何加密的、数字证书如何形成。

1、https是如何加密的：

HTTPS采用的是处理信息的方式是：结合对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的：

服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。

2、数字证书如何形成

数字证书（Digital Certificate）是用来证明公钥（非对称密钥算法中用于加密的密钥）所有者身份的。

1、数字证书是CA对公钥签名：数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）后形成的一个数字文件。

2、数字证书公开的：CA完成签发证书后，会将证书发布在CA的证书库（目录服务器）中，任何人都可以查询和下载，因此数字证书和公钥一样是公开的。实际上，数字证书就是经过CA认证过的公钥。

3、如何认证公钥可靠：我们人人都可以自己生成一个公钥，但是这个公钥是否能代表是你的，这个认证的过程需要一个权威机构执行，这个机构就是证书授权中心。

证书授权中心（Certificate Authority）负责证书颁发。CA 是行业内信得过的组织机构，它具有权威性，由它颁发的证书大家都相信是可靠的。

HTTPS证书其实就是一张数字证书，数字证书的核心就是非对称加密算法。HTTPS证书必须有可信的CA机构才能签发。用户先要产生用与加解密的公私钥对，然后用户把用于加密的公钥以及个人身份信息一起发送给CA机构，CA机构根据用户的公钥和个人信息签发出HTTPS证书。用户从CA机构中得到HTTPS证书后，把HTTPS证书以及自己的私钥部署的web服务器中，这样Web服务器就能够对外提供HTTPS服务了。HTTPS证书产生的整个过程就是如此。

当用户采用HTTPS协议访问你的网站时，首先会从你的服务器中得到HTTPS证书，然后当用户向Web服务器传输数据时，由于HTTPS证书中已经包含了公钥，所以其实是使用了证书中的公钥对传输数据进行加密，然后把密文发送给Web服务器。

Web服务器得到密文后，再使用私钥对密文进行解密，最终得到用户的原文信息。由于用于解密的私钥从始至终都在用户手上，不会被第三者所得到，因此密文信息也不可能被破解，所以使用HTTPS证书的网站我们都认为是安全可靠的（但前提是私钥不会被泄露）。