计算机基础_网络协议2.TCP、HTTP、HTTPS

标签：HTTP 请求 报文 TCP HTTPS 客户端

三次握手和四次挥手详细原理，为什么要使用这种机制？

当进行第一次握手，网络不好可能会堵塞，所以连接的请求并没有到达服务器端；
但是tcp连接有超时重传的机制，所以再一次发送请求，这时候服务器端接收到了你的请求，他也会返回一个请求给你，这是第二次握手；
但是这时候网络环境突然又好了起来，那个堵塞的请求到达了服务器端，服务器端又给你回了一个请求，但是你又不想给服务器发送请求，这时候服务器的资源会进行占用等待你的请求，为了不使服务器的资源继续占用，你又必须发送一个请求给服务器；
所以要进行3次握手。

 

1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 ACK 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

有哪些协议是可靠，TCP有哪些手段保证可靠交付

TCP对应的协议都是可靠传输协议，有：FTP Telnet SMTP POP3 HTTP

手段：

• 面向连接
• 可靠性（有状态、可控制）
• 面向字节流，UDP是基于数据报的

状态就是：确认应答ACK、序列号

可控制就是:超时重发、校验和、提供流量控制

 

常见的状态码有哪些？

1xx：表示消息。代表服务端已经接收到客户端请求，需要继续处理；
2xx：表示成功。代表客户端的请求已成功被服务端接受并处理；
3xx：表示重定向。代表客户端需要进一步的操作才能完成请求；
4xx：表示请求错误。代表客户端请求有问题；
5xx：表示服务端错误。代表服务端在处理请求的过程中出现错误或者当前无法完成对请求的处理。
常见状态码描述文本有如下：
200 OK：请求成功；
204 等同于请求执行成功，但是没有数据，浏览器不用刷新页面，也不用导向新的页面。所以对于一些提交到服务器处理的数据，只需要返回是否成功的情况下，可以考虑使用状态码204来作为返回信息，从而省掉多余的数据传输。
301 永久重定向，浏览器会记住此处重定向，例如a重定向到b，下次不会访问a，直接访问b
302 临时重定向，浏览器不会记住，访问a之后，再告诉浏览器去访问b
304 所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源
400 Bad Request：客户端请求语法有问题，服务端无法理解；
401 Unauthorized：请求未经授权，要求用户的身份认证；
403 Forbidden：服务器收到请求但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因；
404 Not Found：请求的资源不存在，eg，输错了URL；
500 Internal Server Error：服务器发生错误，无法完成客户端请求；
503 Service Unavailable：表示服务器当前不能处理客户端请求，一段时间之后可能恢复正常

HTTP所有状态码的具体含义看到异常状态码能快速定位问题

304表示什么？和302的区别

 

HTTP请求报文和响应报文的具体组成能理解常见请求头的含义，有几种请求方式，区别是什么

 

 HTTP请求报文是由请求行、请求头部、空行和请求数据四部分组成。
（1）请求行由请求方法、uri字段和HTTP协议版本三部分组成，它们之间用空格隔开
（2）请求头部由键值对组成，关键字和值之间用：隔开
（3）最后一个请求头之后是一个空行，通知服务器空行以下是请求数据
（4）请求数据不再GET方法中使用，而是在POST方法中使用

 

 

HTTP响应报文是由状态行、响应头部、空行和响应包体四部分组成。
（1）状态行由HTTP协议版本、状态码和状态描述三部分组成，它们之间用空格隔开
（2）响应头部由键值对组成，关键字和值之间用：隔开
（3）最后一个响应头之后是一个空行，通知服务器空行以下是响应包体
（4）响应包体是服务器返回给客户端的文本信息

请求方式

当客户端发送请求报文时，请求行中就包括了请求方法。HTTP/1.1规定了多种请求方法，都是大写表示：
GET：通常用来获取资源
HEAD：跟GET方法相同，只不过服务器响应时不会返回消息体。这种方法可以用来获取请求中隐含的元信息，而不用传输实体本身
POST：提交数据，如提交表单或上传文件
PUT：向指定资源位置上传其最新内容
DELETE:请求服务器删除指定的页面
CONNECT： 用于代理服务器
OPTIONS：客户端询问服务器支持的请求方法
TRACE：追踪请求-响应的传输路径，主要用于测试和诊断

GET和POST的区别

首先POST用于向服务器提交数据，比如表单数据的提交 上传文件，GET一般用于获取资源信息
具体来看：
（1）从数据的位置来看，GET请求数据放在uri后面，所以私密性和安全性较差，并且数据的类型必须是ASCII字符，并且长度受到限制；而POST请求数据放置在HTTP报文实体的主体里，所以适合传输敏感信息，并且安全性更高，数据类型和长度也没有限制。
（2）从缓存来看，GET请求会被浏览器缓存，留下历史记录，但是post则默认不会
（3）从幂等性来看，GET请求是幂等的，post不是。（幂等表示执行相同的操作，结果也是相同的）

GET请求长度限制这个问题：

注意：（若长度超限，则服务端返回414标识）
1、首先即使有长度限制，也是限制的是整个URI长度，而不仅仅是你的参数值数据长度。
2、HTTP协议从未规定GET/POST的请求长度限制是多少
3、所谓的请求长度限制是由浏览器和web服务器决定和设置的，浏览器和web服务器的设定均不一样，
这依赖于各个浏览器厂家的规定或者可以根据web服务器的处理能力来设定。

介绍一下HTTP的缓存策略

缓存需要考虑很多因素，比如数据是否一直从缓存取、缓存除了给一个失效时间还要给什么，数据未修改能不能不请求了。

http的缓存策略，是由客户端和服务器端共同去控制的，客户端可以通过在请求头里添加Cache-Control等字段来决定是否走缓存，服务器端也可以在响应头中添加Cache-Control等字段来告诉客户端是否可以缓存数据。

具体根据下面这个网址学习

彻底搞懂 Http 缓存策略，切记死背概念！ - 掘金 (juejin.cn)

Connection为keep-alive表示什么？

表示持久连接，比如一一次请求了六个接口，如果开启HTTP持久连接，则此6个请求走同一个TCP连接，走同一条HTTP流，目前服务器默认为5-15秒。

如果HTTP不持久连接，则此 6 个请求需要发起 6 条 TCP 连接（包括三次握手等）。

开启后的优点：

TCP 连接数比较少，所以随之而来和 TCP 相关的优点全都来了。其实和 HTTP 没什么关系，主要是大幅降低服务器端因大量新建 TCP 连接造成的 CPU负载，以及 TCP 传输相关的拥塞控制问题。

开启后的缺点：

这个协议是为 HTTP1.1 而存在的，已经不完全适合现有的网络状况。以前带宽小，瞬时请求高，所以用这个方法降低 TCP 新建。但现在带宽大，并发高。如果 HTTP 服务存在长轮训或较长间隔请求，而且超过 Keep-Alive 的设置（比如 Keep-Alive 5 秒，但轮训周期是 6 秒），则可能会造成大量的无用途连接，白白占用系统资源。

介绍一下HTTPS的工作原理

全称：Hypertext Transfer Protocol Secure ），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和 身份认证 保证了传输过程的安全性 。

HTTPS 在HTTP 的基础下加入 SSL ，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

 

 

两个阶段：

① 证书验证阶段

1. 浏览器发起 HTTPS 请求
2. 服务端返回 HTTPS 证书
3. 客户端验证证书是否合法，如果不合法则提示告警

② 数据传输阶段

1.当证书验证合法后，在本地生成随机数

2.通过公钥加密随机数，并把加密后的随机数传输到服务端

3.服务端通过私钥对随机数进行解密

4.服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

HTTPS和HTTP有什么区别

• HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
• 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
• HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
• http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
• HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

HTTP1.1、HTTP2.0带来的改变

HTTP1.1带来的改变

• 长连接：引入了 TCP 连接复用，即一个 TCP 默认不关闭，可以被多个请求复用
• 并发连接：对一个域名的请求允许分配多个长连接（缓解了长连接中的「队头阻塞」问题）
• 引入管道机制（pipelining），一个 TCP 连接，可以同时发送多个请求。（响应的顺序必须和请求的顺序一致，因此不常用）
• 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
• 新增了一些缓存的字段（If-Modified-Since, If-None-Match）
• 请求头中引入了 range 字段，支持断点续传
• 允许响应数据分块（chunked），利于传输大文件
• 强制要求 Host 头，让互联网主机托管称为可能

HTTP2.0带来的改变

2015 年正式发布的 HTTP/2 默认不再使用 ASCII 编码传输，而是改为二进制数据，来提升传输效率

• 二进制协议： HTTP/1.1版本的头部信息是文本，数据部分可以是文本也可以是二进制。HTTP/2版本的头部和数据部分都是二进制，且统称为‘帧’

• 多路复用： 废弃了 HTTP/1.1 中的管道，同一个TCP连接里面，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来。由于服务器不用按顺序来处理响应，所以避免了“对头堵塞”的问题。

• 头部信息压缩： 使用专用算法压缩头部，减少数据传输量，主要是通过服务端和客户端同时维护一张头部信息表，所有的头部信息在表里面都会有对应的记录，并且会有一个索引号，这样后面只需要发送索引号即可

• 服务端主动推送： 允许服务器主动向客户推送数据

• 数据流： 由于HTTP/2版本的数据包不是按照顺序发送的，同一个TCP连接里面相连的两个数据包可能是属于不同的响应，因此，必须要有一种方法来区分每一个数据包属于哪个响应。HTTP/2版本中，每个请求或者响应的所有数据包，称为一个数据流（stream），并且每一个数据流都有一个唯一的编号ID，请求数据流的编号ID为奇数，响应数据流的编号ID为偶数。每个数据包在发送的时候带上对应数据流的编号ID，这样服务器和客户端就能分区是属于哪一个数据流。最后，客户端还能指定数据流的优先级，优先级越高，服务器会越快做出响应。

缺点就是 在TCP协议级别上仍然存在类似的队头问题，而TCP仍然是Web的构建基础。当 TCP 数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于 TCP 在设计上不遵循 HTTP 之类的高级协议，因此单个丢失的数据包将阻塞所有进行中的 HTTP 请求的流，直到重新发送丢失的数据为止。

HTTP3.0

HTTP/2 由于采用二进制分帧进行多路复用，通常只使用一个 TCP 连接进行传输，在丢包或网络中断的情况下后面的所有数据都被阻塞。

HTTP/2 的问题不能仅靠应用程序层来解决，因此协议的新迭代必须更新传输层。但是，创建新的传输层协议并非易事。传输协议需要硬件供应商的支持，并且需要大多数网络运营商的部署才能普及。

幸运的是还有另一种选择。UDP 协议与 TCP 一样得到广泛支持，但前者足够简单，可以作为在其之上运行的自定义协议的基础。**UDP 数据包是一劳永逸的：没有握手、持久连接或错误校正。**HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC （快速UDP互联网连接）协议。

与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手重新建立与已知主机的连接。

为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

 

 

HTTPS的加密原理，如何开启HTTPS，如何劫持HTTPS请求

如何开启HTTPS

服务器、SSL证书、已备案域名一个、打包项目一个、ftp客户端

如何劫持HTTPS请求

• 黑客用自己的证书+自己的域名
• 证书劫持+用自己的域名
• 域名劫持+自己的证书
• DNS域名劫持+证书劫持
• 域名入侵
• 中间人证书欺骗攻击
• httpsStrip

 

标签：HTTP,请求,报文,TCP,HTTPS,客户端
From： https://www.cnblogs.com/alwaysrun/p/17181855.html