一.HTTP
HTTP是超文本传输协议
1.请求报文的格式
- 请求行：方法(get、post)、url(请求的地址)、协议版本(http1.1)
- 请求的头部字段（key、value的形式）：
首部字段名：值 - 请求的实体主体（get没有、post有）
2. 响应报文的格式
- 响应行：版本、状态码、短语（状态码的描述）
- 首部字段区域（key、value形式）：
- 实体主体
什么是HTTP,你是怎样理解的？（面题）
1.http是一种传输协议。包含请求报文、响应报文。
2.请求报文里面：比如请求的url，请求的方法是get还是post，请求的协- 议版本、一般是http1.1的。上传的参数。
3.响应报文里面：比如状态码，200成功；状态码描述；返回的参数
3.HTTP的请求方式？
get、post、 head、put、delete、options
4. get、post请求区别：
get、post请求区别？（面题）
最简单的区别：
get请求参数以？分割拼接在url后面。post请求参数在body里面。
get参数长度限制2048个字符，post没有限制
get不安全更深一步的区别：--从语义的角度来回答（协议的定义规范回答）：
| 请求方式 | get | post |
|---|---|---|
| 作用 | 获取资源 | 处理资源 |
| 遵循要求 | 安全、幂等、可缓存的 | 非安全的、非幂等的、不缓存的 |
4.1.安全性
不应该引起server端的状态变化。
比如对server端进行访问，不会引起server端数据的变化。get、head、options就满足。
4.2.幂等性
-
同一个请求方法执行一次和在多次的效果完全相同。
(比如每次get请求的效果是一样的，但是如果中间有post也会导致不一样。但是这里是强调的效果) - get、put、delete满足。
4.3.可缓存性：
- 请求是否可以被缓存。
代理会有缓存功能。比如请求的结果是可以缓存起来的，多次请求的结果可能就是缓存里面的。 - 这是定义的一个规范，我们可以遵守也可以不遵守（可缓存、也可不缓存）
你都理解哪些状态码，他们的含义是什么？（面题）
1xx:1开头的
2xx：200 响应成功
3xx：301、302 发生网络重定向
4xx：401、404 客户端本身的请求存在某些问题
5xx：501、502 server某些异常
5.HTTP链接建立流程
如下图：
在发起一个http请求之前，需要通过tcp的三次握手建立链接（就是客户端和服务端的三次交互）。
HTTP建立链接步骤：
第一步骤：TCP的三次握手
1.客户端 发送syn的同步报文到 server端
2.sever端 返回叫ACK的syn同步报文到 客户端
3.客户端会 回应一个确认报文到 server端
第二步：在TCP通道上面进行http请求以及响应、数据的传递
1.客户端 发送http请求到 server端
2.server 回应http响应报文
第三步：四次挥手进行链接断开
TCP的响应完成后，进行TCP 的四次挥手。比如客户端主动 发起链接断开：
1.客户端 发起FIN终止报文到 server端
2.server端收到终止报文之后，返回确认报文ACK给 客户端
3.某一时机， server端 发送FIN,ACK报文 给客户端
4.客户端发送 ACK确认报文到服务端
HTTP建立链接的流程？
从三方面回答：
首先从tcp的三次握手建立客户端和服务端的链接；
再在tcp的这个链接上面进行http请求、响应；
最后进行tcp的四次挥手进行链接的释放；
6.HTTP特点
http特点：无连接、无状态
无连接
无连接就是需要有一个建立链接和释放链接的一个过程。
解决方法：可以使用【http的持久链接】这个方案。无状态
多次发生http请求的时候，如果是同一个用户的话，server端是不知道是同一个用户的。
解决方法：cookie/session。
6.1持久链接
- 非持久链接
每次发送请求都要建立链接（三次握手、四次挥手）
- 持久链接
打开一个tcp通道。在一定时间内，多个http请求可能在同一个tcp链路上面进行传递和响应的。一定时间后断开链接。
可节省tcp建立链接、释放链接的数量。
持久链接涉及到http的哪些头部字段呢？
connection：keep-alive（客户端希望采用持久链接）
time：20 （持久链接多久有效，比如20秒不会断开的，如果20秒之内再次发起同一个IP或者域名请求，就可以复用曾经打开的链接）
max：10（这个链接最多可以发起多少个请求）
怎样判断一个请求是否结束了？
- content-length：1024
这个是请求报文/响应报文头部中的一个字段，保存了响应字段的大小。客户端可以根据所接收的字节数是否到达content-length的值，如果到达了就说明已经接收完毕。- chunked，最后会有一个空的chunked。
post请求的时候，server返回的数据是多次响应返回的，可以通过http的响应字段chunked是否为空判断请求完成没有。（为空表示传输完成）
7.Charles抓包原理是怎么样的？（面题）
利用http的中间人攻击漏斗进行的。
- 中间人攻击
1.对于客户端和server端这个链接建立起来后直接进行响应。
2.中间人/代理服务器。当客户端发起一个请求的时候，中间人进行hook住，并假冒客户端的身份去和server端请求。
3.server端返回响应结果给中间人。中间人再返回结果给客户端。
4.这个中间人是可以进行数据篡改，所以是攻击的。
二 .HTTP与网络安全
1.什么是https
- HTTPS = HTTP+TSL/SSL
HTTPS是由HTTP和SSL/TSL共同组成的。也就是说https比http多了一个安全的模块。
-
HTTPS和HTTP有怎样的区别？
所以说，https是由http和插在传输层之上和应用层之下的tsl和ssl组成的一个传输协议。
2.https的建立链接的流程（面题）
1.客户端 向server端发送一个报文，报文包含（TLS版本号、客户端支持的加密算法、随机数C）
- server返回给客户端一个握手的报文，报文包含（最终使用的加密算法、随机数S、server证书）
3.客户端收到server端的报文后：
- 会对收到的证书进行验证
- 组装
会话秘钥（= 随机数S+随机数C+预主秘钥） - 通过server端的
公钥对预主秘钥进行加密传输
4.server端：
- 通过
私钥解密得到预主秘钥 - 组装会话秘钥（= 随机数S+随机数C+预主秘钥）
- 客户端发送加密的握手消息给server端
6.server端也发送加密的握手消息给客户端，验证安全通道是否正确的完成。
（中间生成的随机数C、S，非对称加密传递的预主私钥都是为了后面得到会话秘钥做准备。
客户端、server端根据C、S、预主秘钥生成会话秘钥。进行传输）
2.1 会话秘钥：
会话秘钥 = 随机数S+随机数C+预主秘钥
2.2https都使用了哪些加密手段？为什么？（面题）
对称加密、非对称加密
1.连接建立过程中使用非对称加密，非对称加密是很耗时的。
(因为加密和解密的方法不一样)
2.后续通信过程使用对称加密
2.3非对称加密
有发送方、接收方。
1.发送方发送“hello”字符串，发送方通过公钥对“hello”进行加密。
2.经过TCP的连接传输到接收方。
3.接收方通过私钥进行解密。
（加密用公钥、解密就用私钥。加密用私钥、解密就用公钥）
2.4 对称加密
1.发送方发送“hello”字符串，发送方通过对称秘钥对“hello”进行加密。
2.经过TCP的连接传输到接收方。
3.接收方通过同一个秘钥进行解密。
（加密和解密使用同一个密钥）
对称加密缺点：
秘钥需要通过tcp连接进行传递，server才能通过秘钥进行解密。在网络传输中如果有中间人攻击就会被捕获到。
三.TCP与UDP（传输层）
- TCP：传输控制协议
- UDP：用户数据报协议
1.UDP(用户数据报协议)
1.1 UDP特点：
无连接
发送UDP数据报的时候不需要建立链接尽最大努力交付
udp是不保证可靠传输的面向报文
既不合并，也不拆分
比如说在应用层、传输层、IP层（网络层）传输过程进行解释：
应用层有个报文，可大可小。不管大小都不会进行拆分传给运输层。
应用层会把报文原封不动作为运输层UDP用户数据报的数据部分，拼接为UDP头部。
UDP数据报作为IP数据报的数据部分拼接到IP首部
1.2 UDP（用户数据报协议）功能
复用、分用；差错检测；
- 1.复用、分用
在建立传输过程中需要IP地址、端口号组成（也就是套接字）。
对于同一个IP地址的电脑上面会有不同的应用，同一个应用上面也可能会使用不同应用层的协议，对应的端口号也不一样。
不管从哪个端口传输数据出去，都可以复用传输层数据报，再经由IP层传输。
这个就是多端口复用。
从接收方来说，IP层接收IP数据报数据，拆分成UDP数据报。每个数据报都会有对应的端口。就可以根据端口进行分发。
- 2.差错检测
UDP数据报进行差错检测：
2. TCP(传输控制协议)
什么是TCP?
tcp特点、tcp功能
1.TCP特点：
- 面向连接
- 可靠传输：保证传输的数据无差错、无重复、按顺序到达
- 面向字节流
- 流量控制
- 拥塞控制
1.1面向连接
数据传输开始之前，需要建立链接，即三次握手。
数据传输结束时，需要断开链接，即四次挥手
为什么是三次握手？
连接时候由于网络原因超时了，客户端会有超时重传策略。
假如是两次握手：
1.客户端发送syn同步报文给server端时，网络发生了超时。
2.客户端会启用超时重传策略，重新syn发送报文给server。server端并不知道是刚刚那个链接没有建立成功，认为又要建立一个连接。
假如是三次握手：
客户端发送syn同步报文给server端，发生超时。
server端发送syn，ACK确认请求给客户端后，会等待客户端发送ACK确认信号。
此时超时了，客户端重启策略发送的是syn信号，不是ACK信号。等不到ACK信号，说明是链接超时了，刚刚的的链接并没有建立成功。
所以，三次握手，更能保证服务端不存在多次链接。
四次挥手为什么要客服端、服务端进行两方面的断开呢？
客户端发起终止报文FIN给给server端；
server发送ACK确认报文给客户端。
-- 此时客户端向服务端的链接已经断开了。server端还可以向客户端发送数据，客户端不可以向server端发送数据了。就是半关闭状态。
在一定时机内，server端会发起终止确认的报文，断开server端到客户端方向的链接。
客户端给server端ACK确认报文。
要进行两方面的断开，是因为客户端和server之间建立的TCP通道是全双攻的（一条通道两个端点都可以进行发送和接收）。
1.2可靠传输
TCP是怎么样保证可靠传输的？（怎么保证报文： 无差错、 不丢失、 不重复、 按序到达）
可靠传输在TCP层面是通过【停止等待协议】实现的：
- 无差错情况
- 超时重传
- 确认丢失
- 确认迟到
无差错情况：
无差错情况下，客户端会按顺序的发送一个报文，得到server端响应后发送下一个报文。
客户端发送分组报文M1,server端给客户端确认。
客户端发送分组报文M2,server端给客户端确认。
客户端发送分组报文M3,server端给客户端确认。
超时重传
如果因为网络等情况，在一定时间内，客户端没有收到server端的反馈：
客户端再次发送报文；
确认丢失
如果因为网络等情况，在一定时间内，客户端没有收到server端的反馈：
客户端再次发送报文；
- 是server端没有发送成功导致客户端没有收到反馈：
- Server端会收到重复的M1报文，丢掉新收到的报文，给客户端回复；
确认迟到
如果因为网络等情况，在一定时间内，客户端没有收到server端的反馈：
客户端再次发送报文；
- 如果是server端在规定时间内没有发给客户端反馈：
- Server端收到重复的M1报文后，丢掉新收到的报文，给客户端回复；
- 客户端多次收到server端反馈，客户端只处理收到的第一次，后面几次就不做响应了。
1.3 面向字节流
对于TCP，发送方和接收方各有一个缓冲区。发送方会把要发送的内容放在缓冲区，接收方接收到数据后也会放到缓冲区。
对于每次发送多少字节，由TCP连接根据情况决定。有可能把发送方的10个字节会拆分成6个字节、4个字节两次发送，有可能把发送方的5个字节、3个字节合并成8个字节一起发送。
1.4 流量控制
通过【滑动窗口协议】实现的。
怎么理解滑动窗口协议？（第三轮面试）
总结：
【滑动窗口协议】
发送方定义为客户端
接收方定义为server端
- 发送方要发送数据的时候，可能由于接收方的接受窗口很小。
- 如果发送方的发送窗口较大的时候，就会以很快的速度进行传输（比如发送方是4G，接收方是很慢的WIFI）。
- 接收方承载不了，就需要接收方去向TCP的首部字段中更改窗口值，来调整发送方的发送速率，从而进行了流量控制。
1.5 拥塞控制
- 慢开始、拥塞避免
- 快恢复、快重传
简单描述TCP慢启动的特点（面题）：
考察的是TCP拥塞控制中：慢开始、拥塞避免。
慢开始、拥塞避免
横轴：交互次数
纵轴：窗口值的大小、拥塞窗口的多少
1.刚开始发送1个报文，如果没有发生拥塞就发送2个报文，仍旧没有拥塞就翻倍，发送4个报文、8个报文、一直到16个报文。这个过程以指数规律增长，叫做慢开始算法。
2.当增加到门限值16的时候，会采用拥塞避免的策略进行发送报文数量的增长。比如17个、18个，是一种线性的增长。当发送的报文数为24的时候，可能就会发生网络拥塞。
（网络拥塞的界定是很复杂的，简单理解为连续发送的三个报文的ACK确认都没有收到，就产生网络拥塞了）
3.网络拥塞产生后，就要采用乘法减小的策略，把发送的报文数量恢复到1,减小给网络层带来的压力。然后重新慢开始....同时把拥塞窗口值降低到之前的一半，例如之前是24，现在减小为12。
在达到窗口门限值之前使用慢开始，到达之后进行拥塞避免加法增大。
快恢复、快重传
是基于慢恢复、拥塞避免实现的。
达到拥塞窗口的上限值之后，回到新的门限值位置开始新的拥塞避免。
DNS解析
你是否了解DNS解析？DNS解析是怎样的过程呢？（面题）
DNS解析是：域名到IP地址的映射，DNS解析采用UDP数据报，且明文。
1. DNS解析过程：
客户端向server端发送请求的时候，需要经历一个域名到IP地址的映射过程：
1.客户端通过DNS协议向DNS服务器请求，进行相应域名的解析。
2.DNS服务器把解析的IP结果返回给客户端。
3.客户端向对应的IP Server发送网络请求。
2.DNS解析查询方式
- 递归查询
- 迭代查询
2.1递归查询
1.客户端向DNS发起域名请求的时候，先访问本地DNS是否知道我要的IP地址，本地DNS知道就进行返回，不知道就去问根域名DNS。
2.根域名DNS知道就返回给本地DNS,本地DNS返回给客户端。根域名DNS不知道的话就去问顶级DNS.....依次类推。。
2.2迭代查询
1.客户端向DNS发起域名请求的时候，先访问本地DNS是否知道我要的IP地址，本地DNS知道就进行返回，不知道就去问根域名DNS。
2.根域DNS不知道，说顶级DNS可能知道，你去问顶级DNS吧，然后本地DNS又去问顶级DNS。
3.DNS解析存在的问题
DNS解析存在哪些常见的问题？（面题）
DNS劫持问题
DNS解析转发问题
3.1 DNS劫持
因为DNS解析是UDP数据报的，并且是明文的。
所以客户端在给DNS服务器发送请求的时候，会被钓鱼DNS劫持，返回一个错误的IP地址给客户端。导致请求的IP Server也是错误的。
DNS劫持与HTTP的关系？（面题）
他们之间没有关系的。
因为DNS解析是发生在HTTP建立之前。
并且DNS解析请求使用UDP数据报，端口号53（HTTP连接是使用TCP进行的）
3.2 DNS解析转发
1.客户端询问本地DNS服务器某一个域名的IP地址时，我们用的是中国移动，中国移动的DNS服务器就会进行域名解析。
某些域名服务商为了节省资源，转发给电信的DNS服务器，让电信DNS服务器解析。
2.电信DNS服务器会去权威的DNS服务器进行解析。权威DNS根据不同的服务商返回不同的IP。返回的就会是电信的IP。
这个就会导致用的移动网络，访问的服务器是电信网络的服务器处理请求。涉及到了跨网访问，有请求效率等问题。
怎么样解决DNS劫持？（面题）
方案一：httpDNS
方案二：长连接
3.2.1 httpDNS
DNS解析，其实是使用DNS协议向DNS服务器的53端口进行请求。
采用httpDNS请求，其实是：使用HTTP协议向DNS服务器的80端口进行请求。就不产生正常的DNS解析，就不会有DNS劫持了。
客户端向httpDNS server发送http get请求获取IP地址。
3.2.2 长连接
1.有客户端、客户端要请求的API server。客户端和API server中间建立一个长连server(可以理解为一个代理服务器)。
2.客户端和长连server中间建立一个长连通道。客户端直接通过长连通道把http请求发给长连server。
3.长连server通过内网专线进行请求。规避了公网DNS劫持的问题。
四. Session/Cookie
HTTP特点有:
无连接：需要有连接和断开的一个过程。比如三次握手、四次挥手。
无状态：同一个用户多次访问server端，server端并不知道是同一个用户。
session/cookie就是HTTP协议无状态特点的补偿。
Cookie
- 什么是cookie？
cookie 主要用来记录用户状态，区分用户；状态保存在客户端
客户端向server端发送请求，server端生成cookie返回给客户端。
客户端把cookie进行保存，每次请求的时候发送给server端。让server端区分用户。
客户端发送的cookie在http请求报文的cookie首部字段中；
服务端设置http响应报文的Set-Cookie首部字段；
怎样修改cookie？
1.新cookie覆盖旧cookie
2.覆盖规则：name、path、domain等字段需要与原cookie一直，才能覆盖怎样删除cookie？
1.新cookie覆盖旧cookie
2.覆盖规则：name、path、domain等字段需要与原cookie一直，才能覆盖
3.设置cookie的expires = 过去的一个时间点，或者maxAge=0，就让之前的cookie无效了怎样保证cookie的安全？
对cookie进行加密处理；
只在https上携带cookie；
设置cookie为httpOnly，防止跨脚本攻击；
Session
session 也是用来记录用户状态，区分用户；状态保存在服务端
session和cookie的区别和联系：
cookie状态保存在客户端
session状态保存在服务端
session依赖于set-Cookie、Cookie这两个方法。
session工作流程
面试总结
