网络篇

TCP可靠传输的保证，和拥塞控制目的和过程

TCP可靠传输的保证：

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

拥塞定义：某段时间，网络资源的供不应求叫做拥塞。

拥塞控制的目的：拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。

拥塞控制的过程：为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd)的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

拥塞控制的四种方法： 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
快重传与快恢复： 在TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

TCP粘包现象原因和解决方法

粘包概念：

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
粘包可能由发送方造成，也可能由接收方造成。
只有TCP有粘包现象，UDP永远不会粘包
粘包不一定会发生

粘包原因：

所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。

发送端原因：由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服务器在接收到消息（数据流）的时候就无法区分哪些数据包是客户端自己分开发送的，这样产生了粘包。

接收端原因：服务器在接收到数据库后，放到缓冲区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个数据包的情况，造成粘包现象。

解决方法：

在每次使用tcp协议发送数据流时,在开头标记一个数据流长度信息,并固定该报文长度(自定义协议).在客户端接收数据时先接收该长度字节数据,判断客户端发送数据流长度,并只接收该长度字节数据,就可以实现拆包,完美解决tcp粘包问题.

四次挥手的过程中CLOSE_WAIT和TIME_WAIT存在的意义，如何查看TIME_WAIT状态的连接数量，为什么TIME_WAIT会过多

CLOSE_WAIT是服务器开始释放连接前的准备阶段，准备开始释放从服务器端到客户端方向的连接，需要考虑查看你是否还有数据发送给对方，如果没有则发送一个FIN报文，开始释放连接；TIME_WAIT是为了保证第四次挥手中服务器可以接收到客户端发送的应答报文ACK，如果没有接收到，服务器重新发送一个FIN报文给客户端，客户端发送ACK后再次进入TIME_WAIT，直到服务器端接收到ACK报文。

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

TCP UDP IP，以太网报文格以及重要字段，报文从一端到另一端的过程

浏览器输入URL并回车的过程，以及相关协议，DNS查询过程

DNS域名解析，得到IP地址

DNS解析流程:
- 在主机查询DNS缓存，如果没有就会给本地的DNS发送查询请求
- 本地的DNS服务器向根域名服务器发送查询请求，根域名服务器返回该域名的一级域名服务器
- 该本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址
解析出IP地址后，根据IP地址和默认端口80和服务器建立连接
浏览器发出读文件（URL中域名后边部分对应的文件）的HTTP请求该请求报文作为TCP三次握手的第三个报文的数据发送给服务器。
服务器对浏览器的请求作出响应，并把对应的html文本发送给浏览器。
释放TCP连接，（TCP四次挥手断开连接）
浏览器解析该HTML文本并显示内容。
过程中用到的协议：
- 域名解析用到DNS协议
- DNS服务器是基于UDP的，因此会用到UDP协议
- 得到IP地址后，浏览器会与服务器建立HTTP连接，用到HTTP协议
- http协议生成GET请求报文，将该报文传给TCP层处理，用到了TCP协议
- 如果用到了HTTPS协议还会对HTTP协议内容进行加密
- TCP层若有需要会对HTTP数据报分片，分片依据路径MTU和MSS
- TCP的数据报会发送给IP层，用到IP协议
- IP层通过路由选择，将数据发送给目的端口
- 以太网协议需要知道目的IP的物理地址，需要用到ARP协议

HTTP1.0 1.1 2.0之间的区别

HTTP1.0与HTTP1.1：

时间：HTTP1.0在1996年使用而1999年开始广泛使用HTTP1.1
缓存处理：HTTP1.0->:header里的IF-Modified-Since，Expires；HTTP1.1->:Entity tag里的 IF- Unmodified-Since, If-Match, If-None-Match来做缓存策略
带宽优化及网络连接的使用：1.0版本存在浪费带宽的现象（客户只要一部分对象，而http将整个对象拿出来）1.1加入了range头域，解决了该问题。
错误通知的管理：HTTP1.1新增24个错误状态响应码。
Host头处理：HTTP1.1请求消息和响应消息都支持Host头域，若无头域，则404报错。
长连接：1.1支持长连接

HTTP2.0和HTTP1.1之间区别：

引入新的二进制格式
实现多路复用（优于长连接）
Header压缩：HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送：HTTP2.0也具有server push功能

什么是长连接，什么是短连接？

长连接指在一个TCP连接上可以连续发送多个数据包（相当于在同一个连接上排队等候），在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此链接，一般需要自己做在线维持
短连接是指通信双方有数据交互时，就建立一个TCP连接（一个连接就发送一个数据包），数据发送完成后，则断开此TCP连接，一般银行都使用短连接

HTTP和HTTPS之间的区别，HTTPS之间建立链接的过程对称加密算法和非对称加密算法

HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTPS建立连接的过程以及对称加密和非对称加密算法

参考链接：https://blog.csdn.net/q781045982/article/details/78553212

HTTP请求有哪些？Get和POST的区别

HTTP请求：

1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

Get请求与Post请求的区别：

从传递参数的方式上，Get请求是通过URL地址栏传递参数，Post请求时通过数据包传递参数；
从传递参数的数量上，Get请求是有限制的，Post请求理论上是没有限制的；
从发送数据包的数量上，Get一般只发送一个数据包（直接将数据发送至服务器端），Post会发送两个数据包（客户端先向服务器端发送一个request head(请求头)请求发送数据，等到服务器端响应并返回一个100状态码，客户端才会发送真正包含数据参数的request body(请求体)至服务器端）；
从安全程度上，Get请求因为是通过URL传递参数，数据直接暴露在地址栏里，所以是不安全的；Post请求是通过request body(请求体)传递的，数据被封装起来了，所以是安全的

Cookie和session的区别。

a) 存储位置不同

cookie的数据信息存放在客户端浏览器上。

session的数据信息存放在服务器上。

b) 存储容量不同

单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。
对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。

c) 存储方式不同

cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。

session中能够存储任何类型的数据，包括且不限于string，integer，list，map等。

d) 隐私策略不同

cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的。

session存储在服务器上，对客户端是透明的，不存在敏感信息泄漏的风险。

e) 有效期上不同

开发可以通过设置cookie的属性，达到使cookie长期有效的效果。

session依赖于名为JSESSIONID的cookie，而cookie JSESSIONID的过期时间默认为-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。

f) 服务器压力不同

cookie保管在客户端，不占用服务器资源。对于并发用户十分多的网站，cookie是很好的选择。

session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量的内存。

g) 浏览器支持不同

假如客户端浏览器不支持cookie：

cookie是需要客户端浏览器支持的，假如客户端禁用了cookie，或者不支持cookie，则会话跟踪会失效。关于WAP上的应用，常规的cookie就派不上用场了。

运用session需要使用URL地址重写的方式。一切用到session程序的URL都要进行URL地址重写，否则session会话跟踪还会失效。

假如客户端支持cookie：

cookie既能够设为本浏览器窗口以及子窗口内有效，也能够设为一切窗口内有效。

session只能在本窗口以及子窗口内有效。

h) 跨域支持上不同

cookie支持跨域名访问。

session不支持跨域名访问。