计算机网络应用层

最新推荐文章于 2024-09-29 14:09:00 发布

Yanní_G

最新推荐文章于 2024-09-29 14:09:00 发布

阅读量148

点赞数

分类专栏：计算机网络文章标签： http https

本文链接：https://blog.csdn.net/XueyinGuo/article/details/115059260

版权

计算机网络专栏收录该内容

3 篇文章 0 订阅

订阅专栏

HTTP

Keep-Alive 和非 Keep-Alive

在这里插入图片描述

非 Keep=Alive

必须为每一个请求的对象建立和维护一个全新的连接。

每一个连接，客户机和服务器两端都要重新分配 TCP 的缓冲区和文件描述符，这给服务器带来的严重的负担

Keep-Alive

保持该 TCP 连接打开

缺点就是当长时间的保持 TCP 连接时容易导致系统资源被无效占用，需要正确地设置 keep-alive timeout 参数，当 TCP 连接在传送完最后一个 HTTP 响应，该连接会保持 keepalive_timeout 秒，之后就开始关闭这个链接。

应用场景

长连接：多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。

短连接：用户数目较多的Web网站的 HTTP 服务一般用短连接。客户端数量过多，若采用长连接势必会使得服务端大量的资源被无效占用，所以一般使用的是短连接。

无连接：即时通信一般使用 UDP，比如微信消息发送

方法种类

GET

请求指定的页面信息，并返回具体内容，通常只用于读取数据。

POST

向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。

二者区别

get 提交的数据会放在 URL 之后，参数直接暴露在 URL 中，会存在安全问题，因此往往用于获取资源信息。而 post 参数放在请求主体中，参数不会被保留，相比更安全，主要用于修改服务器上的资源。
get 方法产生一个 TCP 数据包，post 方法产生两个。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务端响应200，请求成功。

对于POST方式的请求，浏览器会先发送http header给服务端，告诉服务端等一下会有数据过来，服务端响应100 continue，告诉浏览器我已经准备接收数据，浏览器再post发送一个data给服务端，服务端响应200，请求成功。
get 请求只支持 URL 编码，post 请求支持多种编码格式。
get 只支持 ASCII 字符格式的参数，而 post 方法没有限制。
get 提交的数据大小有限制，而 post 方法提交的数据没限制
get 方式需要使用 Request.QueryString 来取得变量的值，而 post 方式通过 Request.Form 来获取。

HTTPs

与HTTP的区别

HTTP 数据都是未加密的，安全性较差。HTTPS 数据传输过程是加密的，安全性较好。
HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80 端口，后者是 443 端口。
HTTPS 协议需要到数字认证机构（Certificate Authority, CA）申请证书，一般需要一定的费用。
HTTP 页面响应比 HTTPS 快，主要因为 HTTP 使用 3 次握手建立连接，客户端和服务器需要握手 3 次，而

HTTPS 除了 TCP 的 3 次握手，还需要经历一个 SSL 协商过程。

如何建立连接的

① 客户端发起一个 HTTPS 请求，并连接到服务器的 443 端口，发送的信息主要包括自身所支持的算法列表和密钥长度等；

② 服务端将自身所支持的所有加密算法与客户端的算法列表进行对比并选择一种支持的加密算法，然后将它和其它密钥组件一同发送给客户端。

③ 服务器向客户端发送一个包含数字证书的报文，该数字证书中包含证书的颁发机构、过期时间、服务端的公钥等信息。

④ 最后服务端发送一个完成报文通知客户端 SSL 的第一阶段已经协商完成。

⑤ SSL 第一次协商完成后，客户端发送一个回应报文，报文中包含一个客户端生成的随机密码串，称为 pre_master_secre，并且该报文是经过证书中的公钥加密过的。

⑥ 紧接着客户端会发送一个报文提示服务端在此之后的报文是采用pre_master_secre 加密的。

⑦ 客户端向服务端发送一个 finish 报文，这次握手中包含第一次握手至今所有报文的整体校验值，最终协商是否完成取决于服务端能否成功解密。

⑧ 服务端同样发送与第 ⑥ 步中相同作用的报文，已让客户端进行确认，最后发送 finish 报文告诉客户端自己能够正确解密报文。

当服务端和客户端的 finish 报文交换完成之后，SSL 连接就算建立完成了，之后就进行和 HTTP 相同的通信过程，唯一不同的是在 HTTP 通信过程中并不是采用明文传输，而是采用对称加密的方式，其中对称密钥已经在 SSL 的建立过程中协商好了。

Session

Session 的主要作用就是通过服务端记录用户的状态

基于 Session 实现的会话保持

在客户端第一次向服务器发送 HTTP 请求后，服务器会创建一个 Session 对象并将客户端的身份信息以键值对的形式存储下来，然后分配一个SessionId给客户端，这个SessionId保存在客户端 Cookie 中，之后每次该浏览器发送 HTTP 请求都会带上 Cookie 中的 SessionId ，服务器根据会话标识就可以将之前的状态信息与会话联系起来，从而实现会话保持。

典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

优点：安全性高，因为状态信息保存在服务器端。

缺点：由于大型网站往往采用的是分布式服务器，浏览器发送的 HTTP 请求一般要先通过负载均衡器才能到达具体的后台服务器，倘若同一个浏览器两次 HTTP 请求分别落在不同的服务器上时，基于 Session 的方法就不能实现会话保持了。

【解决方法：采用中间件，例如 Redis，我们通过将 Session 的信息存储在 Redis 中，使得每个服务器都可以访问到之前的状态信息】

Cookie

Cookie 一般用来保存用户信息 比如

我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
③登录一次网站后访问网站其他页面不需要重新登录。

状态码

分类	分类描述
1XX	指示信息–表示请求正在处理
2XX	成功–表示请求已被成功处理完毕
3XX	重定向–要完成的请求需要进行附加操作
4XX	客户端错误–请求有语法错误或者请求无法实现，服务器无法处理请求
5XX	服务器端错误–服务器处理请求出现错误