计算机网络

计算机网络

1、http协议

​ 1、http:即是超文本传输协议（HyperText Transfer

Protocol），是一个专门在两点之间传输文字，图片，音频，视频等超文本数据的约定和规范,基于TCP/UDP的应用层协议

HTTP 协议是基于 TCP 协议出现的。TCP 协议是一条双向的通讯通道。HTTP 在 TCP 的基础上，规定了 Request-Response 的模式。这个模式决定了通讯必定是由浏览器首先发起的。

​ 2、HTTP特性（优点）：

* 简单：格式为header+body ，容易理解
* 灵活易扩展：各个部分的组成没有被固定死，可以自由扩充，而且工作在应用层，下层可以随意变化（https就是在Http和TCP中间加了SSL/TLS 安全传输层，http/3甚至把TCP层换成了基于udp的QUIC）
* 应用广泛和跨平台
* 无状态：服务器不会去记忆http状态，可减少负担

3、缺点：

* 无状态：没有记忆能力，完成关联性操作比较麻烦（可使用缓存机制弥补（可能会问到缓存相关问题））
* 明文传输：方便了阅读，却暴露了信息，容易被窃取
* 不安全：
  * 明文可能导致消息泄露，
  * 没有验证身份，通信身份可能遭遇伪装
  * 无法证明报文完整性，容易被篡改
  * 队头堵塞问题

4、结构：

​ 起始行：方法 + 路径 + http版本。

​ 头部

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-95JiIXd2-1619007684471)(http://47.98.159.95/my_blog/http/001.png)]

​ 空行：用来区分头部和实体

问: 如果说在头部中间故意加一个空行会怎么样？

那么空行后的内容全部被视为实体。

​ 实体：具体的数据

5、状态码：

- 1xx：临时回应，表示客户端应继续。
- 2xx：请求成功。
  - 200：请求成功。
- 3xx：请求的目标有变化，需要客户端进一步处理。
  - 301&302：永久性与临时性跳转。
  - 304：跟客户端缓存没有更新。
- 4xx：客户端请求错误。
  - 400：请求语法有误
  - 401：无权限访问
  - 403：服务端拒绝服务。
  - 404：请求的页面不存在。
  - 408：等待超时
- 5xx：服务端请求错误。
  - 500：服务器端错误。
  - 501：功能服务端不支持
  - 502：服务端正常，但错误未知
  - 503：服务端暂时性错误，可以一会儿再试。（服务端满）

（还有http1.0，hhtp1.1，http2的坑，以后再补）

​ http0.9：只支持html，只有get请求，无转态码和错误代码

​ http1.0：支持多种文件，支持http头（请求头和响应头），协议的版本信息要随请求一起发送，支持post等请求方法，增加了状态码

​ http1.1：长连接，支持分块/断点续传，管道传输，host头域（URL要带上主机名），队头堵塞问题

​ http2.0：二进制分帧，多路复用，header压缩，服务器推送，数据流优先级

一次完整的http服务

当我们在web浏览器的地址栏中输入：www.baidu.com，具体发生了什么？

1. 对`www.baidu.com`这个网址进行DNS域名解析，得到对应的IP地址
2. 根据这个IP，找到对应的服务器，发起TCP的三次握手
3. 建立TCP连接后发起HTTP请求
4. 服务器响应HTTP请求，浏览器得到html代码
5. 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）（先得到html代码，才能去找这些资源）
6. 浏览器对页面进行渲染呈现给用户
7. 服务器关闭关闭TCP连接

注：

1.DNS怎么找到域名的？

DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器

2.为什么HTTP协议要基于TCP来实现？

TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）

3.最后一步浏览器是如何对页面进行渲染的？

a）解析html文件构成 DOM树
b）解析CSS文件构成渲染树
c）边解析，边渲染
d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

2、TCP和UDP

1、TCP

即传输控制协议：是基于连接的协议，在收发数据前，双方必须建立可靠的连接，是面向字节流的传输

一个tcp建立必须进行三次握手

三次握手

​ （1） 主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；

​ （2）主机B向主机A发送同意连接和要求同步（同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；

​ （3）. 主机A再发出一个数据包确认主机B的要求同步：“我现在就发，你接着吧！”，然后双方就建立了连接这是第三次对话。

​ 为什么是三次不是两次？

根本原因：无法确认客户端的接收能力。
	三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据
	两次即服务端同意连接后即马上准备连接，如果第一次发的请求延时到达，而请求端重发了数据包建立了连接后延时的请求到了服务端，服务端有开启了连接，而请求端并没有开启，则服务端会一直开着一个无用的连接，而三次请求端只要不理重发的响应包，连接就不会建立	

四次挥手

(1)、刚开始双方处于连接状态，如果客户端要断开，就向服务器发送FIN报文，然后进入FIN-WAIT—1状态，同时也进行半关闭状态，无法发送数据，只能接受数据
(2)、服务端接受到后向客户端发送ACK报文确认，并进入CLOSED-WAIT（等待关闭状态），但会继续处理并发送数据给客户端，客户端接受到服务端的确认后状态变为FIN-WIT2状态
(3)、服务端处理完数据后，确定没有需要发送的数据，就在向客户端发送FIN，然后进入LAST-ACK状态
(4)、客户端接收到FIN后，变成TIME-WAIT状态，并发送ACK给服务端，服务端接受到后即关闭连接，而客户端需要等待2个MSL（报文最大生存时间），在这个期间没有收到服务端的重发请求则结束挥手

• 等待2MSL的意义

不等待的话客户端直接跑路，那么服务端如果还有数据包要发给客户端，可是这些数据包还在路上，那么如果客户端的端口被其他应用占用，就会接收到无用的数据包，造成混乱，所以要等服务器发来的数据包都失效在启动其他应用
为什么是2MSL:一个MSL确保四次挥手中客户端最后的ACK能够到达服务端，另一个确保如果服务端没有收到ACK后重传的FIN可以到达

• 为什么是四次

  	因为服务端接受到客户端的FIN后，还需要等所有报文发送完毕后再发送FIN包，所以先发了一个ACK包表示已经收到了客户端的FIN，等处理完后在发FIN，就形成了4次
  	如果是三次，即等服务端发送完所有数据再发送ACK和FIN，那么长时间的时间延迟会使客户端以为FIN没有到达服务端，会一直重发FIN
  

2、UDP

	用户数据报协议，在正式通信前不必与对方先建立连接，不管对方状态就直接发送。这与现在风行的手机短信非常相似：你在发短信的时候，只需要输入对方手机号就OK了。其传输是基于数据报的

​	特点：无状态，不可控，面向数据报

	TCP	UDP
是否连接	面向连接	面向非连接
传输可靠性	可靠	不可靠
应用场合	传输大量的数据，对可靠性要求较高的场合	传送少量数据、对可靠性要求不高的场景
速度	慢	快

3、https

https是在应用层和传输层中间加一层加密层SSL/TLS

1、http和https的区别

* http明文传输，https加密传输
* http三次握手后即建立连接，https在三次握手后还要进行SSL/TLS的握手再加密传输

* http的默认端口为80，http是的端口为443
* https需要向CA申请数字证书

2、通信过程

* https使用混合加密（对称加密+非对称加密）方式保证信息的机密性：
  * 通信前使用非对称加密交换[会话密钥]（客户端与服务端先通过通信协商好加密算法，客户端使用数字证书中的服务器公钥加密生成会话密钥的信息发送给服务器，服务器使用私钥解密，并使用协商算法算出会话密钥）
  * 通信过程使用对称加密加密数据
* 使用摘要算法实现数据完整性
* 使用数字证书保证服务端身份

详细流程：
首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random；
服务器保存随机数 client-random，选择对称加密和非对称加密的套件，然后生成随机数 service-random，向浏览器发送选择的加密套件、service-random 和公钥；
浏览器保存公钥，并利用 client-random 和 service-random 计算出来 pre-master，然后利用公钥对 pre-master 加密，并向服务器发送加密后的数据；
最后服务器拿出自己的私钥，解密出 pre-master 数据，并返回确认消息。
到此为止，服务器和浏览器就有了共同的 client-random、service-random 和 pre-master，然后服务器和浏览器会使用这三组随机数生成对称密钥，因为服务器和浏览器使用同一套方法来生成密钥，所以最终生成的密钥也是相同的。
pre-master 是经过公钥加密之后传输的，所以黑客无法获取到 pre-master，这样黑客就无法生成密钥，也就保证了黑客无法破解传输过程中的数据了

4、HTTP请求方法

1、请求方法

GET: 通常用来获取资源
HEAD: 获取资源的元信息
POST: 提交数据，即上传数据
PUT: 修改数据
DELETE: 删除资源(几乎用不到)
CONNECT: 建立连接隧道，用于代理服务器
OPTIONS: 列出可对资源实行的请求方法，用来跨域请求
TRACE: 追踪请求-响应的传输路径

2、GET和POST的区别

* 从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
* 从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
* 从参数的角度，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合传输敏感信息。
* 从幂等性的角度，GET是幂等的，而POST不是。(幂等表示执行相同的操作，结果也是相同的)
* 从TCP的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)

5、URI

也就是统一资源标识符，用来区分互联网上不同的资源。

结构：

URI  Uniform Resource Identifier 统一资源标识符
URL  Uniform Resource Locator 统一资源定位符
URN  Uniform Resource Name 统一资源名称

6、TCP快速打开的原理

原理

首轮三次握手
	首先客户端发送`SYN`给服务端，服务端接收到。
注意哦！现在服务端不是立刻回复 SYN + ACK，而是通过计算得到一个`SYN Cookie`, 将这个`Cookie`放到 TCP 报文的 `Fast Open`选项中，然后才给客户端返回。
客户端拿到这个 Cookie 的值缓存下来。后面正常完成三次握手。
首轮三次握手就是这样的流程。而后面的三次握手就不一样啦！

后面的三次握手
	在后面的三次握手中，客户端会将之前缓存的 `Cookie`、`SYN` 和`HTTP请求`(是的，你没看错)发送给服务端，服务端验证了 Cookie 的合法性，如果不合法直接丢弃；如果是合法的，那么就正常返回`SYN + ACK`。
重点来了，现在服务端能向客户端发 HTTP 响应了！这是最显著的改变，三次握手还没建立，仅仅验证了 Cookie 的合法性，就可以返回 HTTP 响应了。
当然，客户端的`ACK`还得正常传过来，不然怎么叫三次握手嘛。

优势

TFO 的优势并不在与首轮三次握手，而在于后面的握手，在拿到客户端的 Cookie 并验证通过以后，可以直接返回 HTTP 响应，充分利用了1 个RTT(Round-Trip Time，往返时延)的时间提前进行数据传输，积累起来还是一个比较大的优势。