[Linux][网络][HTTP协议][Cookie][Session]详细讲解

---

0.HTTP简介

• HTTP(Hyper Text Transfer Protocol)协议又叫做超文本传输协议，是一个简单的请求 – 响应协议
• HTTP通常运行在TCP之上

---

1.认识URL

• 平时俗称的"网址"其实就是说的URL(统一资源定位符)
• IP加端口可以定位互联网上唯一一台主机，但如果还需要该主机上的资源文件，还要有路径
  • 即：通过IP+路径，就可以唯一地确认一个网络资源
• IP通常是以域名的方式呈现的，路径就是Linux主机上的目录

• **协议方案名：**http、https协议或其他

• **登录信息(认证)：**指定用户名和密码作为服务端获取资源时的必要信息，此项为可选项，浏览器显示时会隐藏

• **服务器地址：**访问服务器时必须指明服务器地址，上图给出的只是便于人们记忆的网址，实际会由DNS(域名解析器)进行解析

• **服务器端口号：**指定服务器连接的网络端口号，也是一个可选项，其中有些当口号非常有名，属于强绑定了，如果用户省略则会使用默认的端口号

  • 注意：用户自己写的网络服务bind端口的范围一定是1024之后的，因为前1023个是给这些httpserver服务的 – [0, 1023]

• **带层次的文件路径：**指定服务器的文件路径来定位指定的资源

• 查询字符串：

  • **?前面的是基本的URL格式，如果需要传入参数，在?后面加入，以K-V形式**传入
  • 这些K-V键值对，通过&分开

• **片段标识符：**对资源的部分补充

---

2.urlencode和urldecode

• **编码：在搜索关键字中出现了像/ ? @**这样的字符，由于这些字符已经被URL当作特殊意义理解了，因此URL在呈现时，会对这些特殊字符进行转义
• **解码：**当服务器拿到对应的URL后，也需要对编码后的参数进行解码，此时服务器才能拿到想要传递的参数
  • 解码实际上就是编码的逆过程
  • 转义的过程称为urlencode，其逆过程称为urldecode
• **转义规则：**将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY 格式
  • **比如：百度搜索C++时，由于+**在URL当中也是特殊符号，而+字符转为十六进制后的值就是0x2B，因此一个+就会被编码成一个%2B
• **注意：**URL除了会对这些特殊字符做编码，对中文也会进行编码

---

3.HTTP协议格式

1.HTTP报文

• 用于HTTP协议交互的信息被称为HTTP报文
  • 客户端的HTTP报文叫做请求报文，服务器端的叫做响应报文
• HTTP****报文本身是有多行数据构成的字符串文本
• HTTP报文大致可分为报文首部和报文主体两块，**两者由空行来划分。**通常，并不一定要有报文主体
  

2.HTTP协议请求格式

• HTTP请求由以下四部分构成**(每行以\r\n结尾)**

  • 其中，前面三部分一般是HTTP协议自带的，是由HTTP协议自行设置的
  • 而请求正文一般是用户的相关信息或数据，如果用户在请求时没有信息要上传给服务器，此时请求正文就为空字符串
    

• 请求行：[请求方法]+[url]+[http版本]

  • [url]一般省略了域名和端口，只有路径
  • http协议请求时大小写是忽略的
    • **例如：**请求行的GET / HTTP/1.1 和 get / http/1.1是一样的

• 请求报头：请求的属性，这些属性都是以key: value的形式按行陈列的(: 和value中间有空格)

• **空行：**遇到空行表示请求报头结束

  • 因为只包含了\r\n，用于做分隔符，把报头和有效载荷分离

• 请求正文：请求正文允许为空字符串，如果请求正文存在，则在请求报头中会有一个Content-Length属性来标识请求正文的长度

• 如何将HTTP请求的报头与有效载荷进行分离？

  • 可以根据HTTP请求当中的空行来进行分离，当服务器收到一个HTTP请求后，就可以按行进行读取
    • 如果读取到空行则说明已经将报头读取完毕，实际HTTP请求当中的空行就是用来分离报头和有效载荷的
  • 如果将HTTP请求想象成一个大的线性结构，此时每行的内容都是用\r\n隔开的
    • 因此在读取过程中，如果连续读取到了两个\r\n，就说明已经将报头读取完毕了，后面剩下的就是有效载荷了

• 注意：

  • 浏览器向我们的服务器发起HTTP请求后，因为我们的服务器没有对进行响应，此时浏览器就会认为服务器没有收到，然后再不断发起新的HTTP请求，因此虽然我们只用浏览器访问了一次，但会受到多次HTTP请求
  • URL****当中的/不能称之为服务器的根目录，这个/表示的是web根目录
    • 这个web根目录可以是机器上的任何一个目录，这个是可以自己指定的，不一定就是Linux的根目录

3.HTTP响应协议格式

• HTTP响应由以下四部分构成**(每行以\r\n结尾)**
  

• 状态行：[http版本]+[状态码]+[状态码描述]

• 响应报头：响应的属性，这些属性都是以key: value的形式按行陈列的(: 和value中间有空格)

• **空行：**遇到空行表示响应报头结束

  • 因为只包含了\r\n，用于做分隔符，把报头和有效载荷分离

• 响应正文：响应正文允许为空字符串，如果响应正文存在，则响应报头中会有一个Content-Length属性来标识响应正文的长度

  • 比如：服务器返回了一个html页面，那么这个html页面的内容就是在响应正文当中的

---

4.HTTP的方法

方法	说明	支持的HTTP协议版本
GET	获取资源	1.0**、1.1**
POST	传输实体主体	1.0**、1.1**
PUT	传输文件	1.0**、1.1**
HEAD	获取报文首部	1.0**、1.1**
DELETE	删除文件	1.0**、1.1**
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

• 其中最常用的就是GET方法和POST方法
  • GET请求主要用于从服务器获取实体资源，资源可被缓存，可以记录历史记录
  • POST请求主要用于向服务器提交表单数据
    • 因此POST请求不会被缓存，POST请求不会保留在浏览器历史记录当中，POST请求不能被保存为书签
• HEAD请求是没有响应主体的，仅传输状态行和标题部分
• DELETE方法用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容
• PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容
  • 如果请求URI(Request-URI)指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器关于此URI所指定资源实体的最新修改版本。
  • 如果请求URI(Request-URI)指定的资源不存在，并且此URI被用户代理定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此URI所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代理(user agent)发送201(已创建)响应。如果已存在的资源被改变了，那么源服务器应该发送200(Ok)或者204(无内容)响应

1.表单

• 网络行为无非有两种
  • 想把远端的资源拿到本地
  • 想把属性字段提交到远端
• 提交到远端有两种方法：GET、POST

2.GET vs POST

• 概念问题：

  • GET – 获取，是最常用的方法
    • 默认一般获取所有的网页，都是GET方法，但是如果GET要提交参数，通过URL来进行参数拼接从而提交给server端
  • POST – 推送，是提交参数比较常用的方法
    • 但是如果提交参数，一般是通过正文部分提交的
  • 当想获取某种资源的时候，大部分都是GET，但如果想提交参数既可以是GET也可以是POST

• 区别：提交参数的位置不同

  • GET通过URL传参
    • GET方法不私密，会将重要信息回显到url的输入框中，增加了被盗取的风险
    • URL是有大小限制的，和具体的浏览器有关
      • Http Get方法提交的数据大小长度并没有限制，HTTP协议规范没有对URL长度进行限制
      • 这个限制是特定的浏览器及服务器对它的限制，而这个限制是实实在在存在的
  • POST通过正文传参
    • POST方法比较私密，不会回显到浏览器的URL输入框
      • **注意：**私密!=安全，加密和解密才是安全
    • 由正文部分传参，一般大小没有限制
      • 理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制
      • 起限制作用的是服务器的处理程序的处理能力，而并非限制

• 如何选择？

  • GET：如果提交的参数不敏感，且数量较少，可以采用GET
  • **POST：**否则，就是用POST

---

5.HTTP状态码

	类别	原因短语
1XX	**Informational(**信息性状态码)	接收的请求正在处理
2XX	**Success(**成功状态码)	请求正常处理完毕
3XX	**Redirection(**重定向状态码)	需要进行附加操作以完成请求
4XX	**Client Error(**客户端错误状态码)	服务器无法处理请求
5XX	**Server Error(**服务器错误状态码)	服务器处理请求出错

• 最常见的状态码，比如：200(OK)，404(Not Found)，403(Forbidden)，302(Redirect，重定向)，504(Bad Gateway)

1.3XX – 重定向状态码

• 重定向就是通过各种方法将各种网络请求重新定个方向转到其它位置，此时这个服务器相当于提供了一个引路的服务，且返回的响应response报头里会携带http的响应属性Location：new url，此时就会重定向到新的url网址
• 重定向又可分为临时重定向和永久重定向，其中状态码301表示的就是永久重定向，而状态码302和307表示的是临时重定向
• 临时重定向：
  • 该状态码表示请求的资源已被分配了新的URL，希望用户(本次)能使用新的URL访问
• 永久重定向：
  • 该状态码表示请求的资源已被分配了新的URL，以后使用资源应访问现在所指的URL
  • 也就是说，如果已经把资源对应的URL保存为书签了，这时应该按Location首部字段提示的URL重新保存
• 临时重定向 vs 永久重定向：
  • 网站1如果临时不想被访问就用 302 暂时重定向到网站2
  • 网站1如果永久不想被访问就用 301 永久重定向到网站2
• 几个重定向状态码
  • 301
    • 表明目标资源被永久的移动到了一个新的URI，任何未来对这个资源的引用都应该使用新的URI
  • 302
    • 表示目标资源临时移动到了另一个URI上。由于重定向是临时发生的，所以客户端在之后的请求中还应该使用原本的URI
    • 由于历史原因，用户代理可能会在重定向后的请求中把POST方法改为GET方法
      • 如果不想这样，应该使用307(Temporary Redirect)状态码
  • 303
    • 表示服务器要将浏览器重定向到另一个资源
    • 从语义上讲，重定向到的资源并不是你所请求的资源，而是对你所请求资源的一些描述
      • 比如303常用于将POST请求重定向到GET请求
      • 比如你上传了一份个人信息，服务器发回一个303响应，将你导向一个"上传成功"页面
  • 307
    • 定义实际上和302是一致的
    • 唯一的区别在于，307状态码不允许浏览器将原本为POST的请求重定向到GET请求上
  • 308
    • 定义实际上和301是一致的
    • 唯一的区别在于，308状态码不允许浏览器将原本为POST的请求重定向到GET请求上

---

6.HTTP常见Header

• Content-Type：数据类型(text/html等)
  • 比如Content-Type：text/html; charset=utf-8用于表示正文是 text/html文档类型，字符集为utf-8
  • 大小写不敏感
• Content-Length**：**Body的长度
• Host**：**客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上
• User-Agent**：**声明用户的操作系统和浏览器版本信息
• referer**：**当前页面是从哪个页面跳转过来的
• Location**：**搭配3xx状态码使用，告诉客户端接下来要去哪里访问
• Cookie**：**用于在客户端存储少量信息，通常用于实现会话(session)的功能

---

7.Cookie

0.情景铺垫

• HTTP****实际上是一种无状态协议，HTTP的每次请求/响应之间是没有任何关系的，但在使用浏览器的时候发现并不是这样的
  • 比如当你登录一次B站后，就算你把B站关了甚至是重启电脑，当你再次打开B站时，B站并没有要求你再次输入账号和密码，这实际上是通过cookie技术实现的，点击浏览器当中锁的标志就可以看到对应网站的各种cookie数据
  • 这些cookie数据实际都是对应的服务器方写的，如果你将对应的某些cookie删除，那么此时可能就需要你重新进行登录认证了，因为你删除的可能正好就是你登录时所设置的cookie信息

1.cookie的登陆策略

• 登录策略分为如下三步
  • 当第一次登陆某网站时，客户端向服务器输入用户名和密码
  • 服务器把cookie用户名&&密码返回给客户端(在HTTP请求中的Cookie是明文传递的)
  • 客户端下次登录自动携带浏览器访问该网站对应的cookie文件中的内容，这样就能保持登录
• 总结：
  • 第一次登录时，服务器就会进行Set-Cookie的设置(Set-Cookie****也是HTTP报头当中的一种属性信息)
  • 当认证通过并在服务端进行Set-Cookie设置后，服务器在对浏览器进行HTTP响应时就会将这个Set-Cookie响应给浏览器
  • 而浏览器收到响应后会自动提取出Set-Cookie的值，将其保存在浏览器的cookie文件当中，此时就相当于账号和密码信息保存在本地浏览器的cookie文件当中
  • 从第一次登录认证之后，浏览器再向该网站发起的HTTP请求当中就会自动包含一个cookie字段，其中携带的就是第一次的认证信息，此后对端服务器需要对你进行认证时就会直接提取出HTTP请求当中的cookie字段，而不会重新让你输入账号和密码了
    • 也就是在第一次认证登录后，后续所有的认证都变成了自动认证，这就叫做cookie技术
      

2.cookie的风险

• 仅仅是cookie的登陆策略会存在安全隐患：
  • 当你不小心被迫下载了木马病毒，该病毒会扫描你的浏览器当中的cookie目录，它就会把所有的cookie信息通过网络的方式传给黑客，你的cookie用户名密码可能会被盗取，黑客会拿着你的cookie去登录，更严重的是黑客会修改你的cookie密码对账号产生威胁
  • 因此单纯的使用cookie是非常不安全的，因为此时cookie文件当中就保存的是你的私密信息，一旦cookie文件泄漏你的隐私信息也就泄漏
• 解决办法就是使用cookie + session的登陆策略

3.注意点

• 所以Cookie到底是什么？
  • Cookie是一种保存在客户端的小型文本文件，用于保存服务器通过Set-Cookie字段返回的数据，在下次请求服务器时通过Cookie字段将内容发送给服务器。是HTTP进行客户端状态维护的一种方式
  • Cookie可以记录用户的ID，记录用户的密码，记录用户浏览过的商品记录。但是无法记录用户的浏览器设置(浏览器设置属于浏览器，而并不属于某次请求的信息)
  • Cookie只能存储字符串
• Set-Cookie以及Cookie字段可以包含有多条信息，也可以由多个Cookie及Set-Cookie字段进行传输多条信息
• Cookie****有生命周期，在超过生命周期后Cookie将失效，对应的Cookie文件将被删除
• Cookie安全机制，Cookie有哪些设置可以提高安全性？
  • **domain：**可以访问该Cookie的域名
    • 如果设置为".google.com"，则所有以"google.com"结尾的域名都可以访问该Cookie
    • 注意第一个字符必须为“.”
  • **path：**Cookie的使用路径
    • 如果设置为"/sessionWeb/“，则只有contextPath为”/sessionWeb"的程序可以访问该Cookie
    • 如果设置为"/"，则本域名下contextPath都可以访问该Cookie
    • 注意最后一个字符必须为“/”
  • **httponly：**如果Cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到Cookie信息，这样能有效的防止XSS攻击，窃取Cookie内容，这样就增加了cookie的安全性，但不是绝对防止了攻击
  • **secure：**该Cookie是否仅被使用安全协议传输
    • 安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密
    • 默认为false。
  • **expires：**指定了Coolie的生存期
    • 默认情况下cookie是暂时存在的，他们存储的值只在浏览器会话期间存在，当用户退出浏览器后这些值也会丢失
    • 如果想让Cookie存在一段时间，就要为expires属性设置为未来的一个过期日期
    • 现在已经被max-age属性所取代，max-age用秒来设置cookie的生存期
• Cookie缺陷：有大小限制，通常不能超过4K

---

8.Session

1.session介绍

• 单纯的使用cookie是非常不安全的，因为此时cookie文件当中就保存的是你的私密信息，一旦cookie文件泄漏你的隐私信息也就泄漏
• 所以当前主流的服务器还引入了SessionID这样的概念，当第一次登录某个网站输入账号和密码后，服务器认证成功后还会在服务端生成一个对应的SessionID，这个SessionID与用户信息是不相关的。系统会将所有登录用户的SessionID值统一维护起来
• 此时当认证通过后服务端在对浏览器进行HTTP响应时，就会将这个生成的SessionID值响应给浏览器。浏览器收到响应后会自动提取出SessionID的值，将其保存在浏览器的cookie文件当中，后续访问该服务器时，对应的HTTP请求当中就会自动携带上这个SessionID
• 而服务器识别到HTTP请求当中包含了session_id，就会提取出这个session_id，然后再到对应的集合当中进行对比，对比成功就说明这个用户是曾经登录过的，此时也就自动就认证成功了，然后就会正常处理你发来的请求，这就是当前主流的工作方式
  

2.session是相对安全的

• 引入session_id之后，浏览器当中的cookie文件保存的是session_id，此时这个cookie文件同样可能被盗取。此时用户的账号和密码虽然不会泄漏了，但用户对应的session_id是会泄漏的，非法用户仍然可以盗取session_id去访问用户曾经访问过的服务器，相当于还是存在刚才的问题
• 之前的工作方式就相当于把账号和密码信息在浏览器当中再保存一份，每次请求时都自动将账号和密码的信息携带上，但是账号和密码一直在网络中发送太不安全了
• 因此现在的工作方式是，服务器只有在第一次认证的时候需要在网络中传输账号和密码，此后在网络上发送的都是session_id
• 这种方法虽然没有真正解决安全问题，但这种方法是相对安全的
• 互联网上是不存在绝对安全这样的概念的，任何安全都是相对的，就算你将发送到网络当中的信息进行加密，也有可能被别人破解

3.引入session后的好处

• 在引入SessionID之前，用户登录的账号信息都是保存在浏览器内部的，此时的账号信息是由客户端去维护的
• 而引入SessionID后，用户登录的账号信息是有服务器去维护的，在浏览器内部保存的只是SessionID
• 此时虽然SessionID可能被非法用户盗取，但服务器也可以使用各种各样的策略来保证用户账号的安全
• IP是有归类的，可以通过IP地址来判断登录用户所在的地址范围。如果一个账号在短时间内登录地址发送了巨大变化，此时服务器就会立马识别到这个账号发生异常了，进而在服务器当中清除对应的SessionID的值。这时当你或那个非法用户想要访问服务器时，就都需要重新输入账号和密码进行身份认证，而只有你是知道自己的密码的，当你重新认证登录后服务器就可以将另一方识别为非法用户，进而对该非法用户进行对应的黑名单/白名单认证
• 当操作者想要进行某些高权限的操作时，会要求操作者再次输入账号和密码信息，再次确认身份。就算你的账号被非法用户盗取了，但非法用户在改你密码时需要输入旧密码，这是非法用户在短时间内无法做到的，因为它并不知道你的密码。这也就是为什么账号被盗后还可以找回来的原因，因为非法用户无法在短时间内修改你的账号密码，此时你就可以通过追回的方式让当前的SessionID失效，让使用该账号的用户进行重新登录认证
• SessionID也有过期策略
  • 比如SessionID是一个小时内是有效的。所以即便你的SessionID被非法用户盗取了，也仅仅是在一个小时内有效，而且在功能上受约束，所以不会造成太大的影响
  • 默认有效期是30分钟

4.注意点

• Session可以存放各种类被的数据，相比只能存储字符串的cookie，能给开发人员存储数据提供很大的便利
• 如果浏览器禁用了Cookie，Session机制会不会失效？
  • 不会
  • 一般情况下Session是通过Cookie传递Session_ID实现的，禁用cookie则session就没法用了
  • 但是劳动人民智慧是无穷的，可以将SESSION_ID附着在URL中来实现，也就是Session并不一定完全依赖于Cookie实现

---

9.Connection

1.Connection: closed —— 短链接

• 短链接一次只能处理一条http请求
• 用户所看到的完整的网页内容 – 背后可能是无数次http请求，每个图片就是一个文件，就需要一次请求
• http底层主流采用的就是tcp协议，每处理一次请求就会进行一次三次握手与四次挥手链接
  • 一个网页有上百次http请求，就要进行上百次的三次握手与四次挥手
  • 则短链接不再适用

2.Connection: keep-aliye —— 长链接

• 双方都同意采用长链接方案时，请求和响应中都携带了Connection: keep-aliye
• 客户端建立一个tcp链接，这一个tcp链接发送多次http请求，服务器接收后通过这个链接返回给客户端多次响应，当所有响应全部返回，此链接才断开。不用再向短链接那样重复建立链接了，大大提高了效率

3.http协议无连接解释

• HTTP定义：超文本传输协议，是一个 无连接，无状态的应用层协议
• http协议底层是tcp，tcp是面向连接的，http只是使用了tcp的连接能力，但是http本身是无链接的