网站建设毕业设计总结对网络营销的理解

2. HTTP协议

2.1 HTTP协议简介

HTTP协议，全称超文本传输协议（Hypertext Transfer Protocol），是从WEB服务器传输超文本标记语言（HTML）到本地浏览器的传送协议。

• 设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
• HTTP协议有多个版本，目前广泛使用的是HTTP/1.1版本。
• HTTP协议是一个无状态协议（stateless）
  • 无状态的理解：服务器不维护任何有关客户端过去所发请求的消息。
  • 有状态协议会更加复杂，因为需要维护状态（即历史信息），而如果客户端或服务器失效，产生的状态会不一致，解决这种不一致的代价更高。
• HTML是一门语言，全称是超文本标记语言，超文本的意思就是不只是文本，还可以包含图片、链接、音乐甚至程序等非文字元素。
• 网络协议：是计算机之间为了实现网络通信而达成的一种“约定”或者“规则”，这样不同厂商的生产设备以及不同操作系统组成的计算机之间，都可以实现通信。

2.2 HTTP协议的优点

• HTTP协议支持客户端/服务端模式，也是一种请求/响应模式的协议。
• 简单快速：客户端向服务器请求服务时，只需传送请求方法和路径。
  • 请求方法常用的有GET、POST、HEAD
• 灵活：HTTP允许传输任意类型的数据对象，传输的类型由Content-Type加以标记。
• 无连接：限制每次连接都只处理一个请求。当服务器处理完请求，并收到客户端的应答之后，就会断开连接（短连接）。
  • 但是这种无连接却不利于客户端和服务器保持会话连接。为了弥补这种不足，产生了两项记录HTTP状态的技术：Cookie和Session。
• 无状态：指协议对于事务处理没有记忆。若后续处理需要前面的信息，则必须重传。

2.3 HTTP协议的缺点

• 请求信息明文传输，容易被窃听截取。
• 数据的完整性未校验，容易被篡改
  • 所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。
• 没有验证对方身份，存在冒充危险
  • HTTP协议中的请求和响应不会对通信方进行确认。任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉。

2.4 HTTP协议属于哪一层

HTTP属于应用层协议，以TCP协议（传输层）作为底层协议（用于识别该连接请求，解封包，一层一层的剥开），默认端口是80（注意是服务器的端口）。

2.5 HTTP通信过程

HTTP通信是指HTTP客户端（即浏览器）通过URL向HTTP服务端（即WEB服务器）发送请求。

• 服务器在80端口等待客户端请求
• 浏览器输入URL，经过DNS域名解析为服务器IP
• 浏览器发送TCP请求，通过三次握手建立和服务器的连接（创建套接字Socket）
  • 浏览器是以随机端口发送的请求，而服务器是以80端口接收的请求
• 浏览器发送HTTP请求，服务器返回HTTP响应，即交换HTTP消息
• 客户端将相应得到的HTML代码和资源渲染到前端给用户
• 关闭TCP连接

2.6 常见请求方法

• GET：请求指定的页面信息，并返回实体主体。
• POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）
  • 数据被包含在请求体中
  • POST请求可能会导致新的资源建立或已有资源的修改
• HEAD：类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头
• PUT：从客户端向服务器传送的数据取代指定的文档的内容
• DELETE：请求服务器删除指定的页面

2.7 GET和POST的区别

• 结构：都包含请求头和请求行，POST多了一个请求正文body。

• 用途：GET多用来查询，请求参数放在URL中，不会对服务器上的内容产生作用。POST多用来提交，如把账号密码放在body中。

• 安全性：GET是直接添加在到URL后面的，直接就可以在URL中看到内容，而POST是放在报文内部的，用户无法直接看到，比较安全。

  • GET方式请求的参数会跟在URL后面，以**?来分隔URL和参数，如果有多个参数，那么参数之间使用&**连接

• 长度限制：GET提交的数据长度是有限制的，因为URL有长度限制，具体的长度限制是由浏览器决定的。而POST没有长度限制。

• 缓存：GET可以被缓存，而POST不能被缓存

• 历史：GET参数保存在浏览器历史中，而POST不会。

• 后退按钮/刷新：GET请求来说，无害。对于POST请求来说，数据会被重新提交（浏览器应该告知用户数据会被重新提交）。

  

2.8 请求报文与响应报文

2.8.1 HTTP请求报文

请求报文包含三个部分：

• 请求行

  • 请求行包含请求方法、URL、协议/版本

• 请求头

  • 请求头包含许多有关客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。
  • User-Agent：HTTP客户端运行的浏览器类型的详细信息。通过该头部信息，web服务器可以判断到当前HTTP请求的客户端浏览器类别。
  • Accept：指定客户端能够接收的内容类型，内容类型中的先后次序表示客户端接收的先后次序。实例：Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.8,image/png,*/*;q=0.5
  • Accept-Language：指定HTTP客户端浏览器用来展示返回信息所优先选择的语言。
  • Accept-Encoding：指定客户端浏览器可以支持的web服务器返回内容压缩编码类型。表示允许服务器在将输出内容发送到客户端以前进行压缩，以节约带宽。而这里设置的就是客户端浏览器所能够支持的返回压缩格式。
  • Accept-Charset：浏览器可以接受的字符编码集。实例：Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
  • Content-Type：显示此HTTP请求提交的内容类型。一般只有post提交时才需要设置该属性。实例：Content-type: application/x-www-form-urlencoded;charset:UTF-8
  • Content-Length：表示web服务器返回消息正文的长度
  • Connection：表示是否需要持久连接。
  • cookie：HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。
  • Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面
  • Cache-Control：指定请求和响应遵循的缓存机制。
  • Date：消息发送的时间，服务器响应中要包含这个头部，因为缓存在评估响应的新鲜度时要用到。
  • Via：列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用什么协议（和版本）发送的请求。当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面添加 Via 头部，并填上自己的相关信息，当下一个代理服务器 收到第一个代理服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via头部，并把自己的相关信息加到后面，以此类推，当 OCS 收到最后一个代理服务器的请求时，检查 Via 头部，就知道该请求所经过的路由。例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)

• 请求正文

  • GET请求不包含，POST请求包含
  • 请求正文中可以包含客户提交的查询字符串信息

例子：

POST/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflateusername=jinqiao&password=1234

**Note：**请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。这个空行发送回车符和换行符，通知服务器以下不再有请求头。

2.8.2 HTTP响应报文

响应报文包含三个部分：

• 状态行
  • 状态行由协议版本、数字形式的状态码、及相应的状态描述，各元素之间以空格分隔。
• 响应头
• 响应正文
  • 响应正文包含着我们需要的一些具体信息，比如cookie，html，image，后端返回的请求数据等等。

**Note：**响应正文和响应头之间有一行空行，表示响应头的信息到空行为止。

2.9 响应状态码

状态码分类常见状态码：

• 1XX：信息型，服务器收到请求，客户端可继续发送请求

• 2XX：成功型：服务器成功收到请求，理解并处理

  • 200 OK：客户端请求成功

  • 204 No Content 成功，但不返回任何实体的主体部分

  • 206 Partial Content 成功执行了一个范围（Range）请求

• 3XX：重定向，服务器要求客户端重定向

  • 301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL
  • 302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源
  • 303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源
  • 304 Not Modified 服务器内容没有更新，可以直接读取浏览器缓存

• 4XX：客户端错误，客户端的请求包含语法错误或无法完成请求

  • 400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解
  • 401 Unauthonzed 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
  • 403 Forbidden 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
  • 404 Not Found 请求的资源不存在，例如，输入了错误的URL

  

• 5XX：服务器错误，服务器在处理请求的过程中发生了错误

  • 500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求
  • 503 Service Unavailable 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常
    • 503 Service Unavailable的原因及如何解决

2.10 HTTP 1.0和1.1的区别

2.10.1 长连接

在HTTP/1.0中，默认使用的是短连接，也就是每次请求都要重新建立一次连接。采用TCP协议保证可靠传输时，每次建立连接和断开连接都需要进行三次握手和四次挥手。如果每次都这样的话，开销比较大，因此从HTTP/1.1起，默认采用长连接。在请求头中的参数为Connection: keep-alive。

HTTP/1.1 的持续连接，有非流水线方式和流水线方式 。

• 流水线方式，是客户在收到 HTTP 的响应报文之前，就能接着发送新的请求报文；
• 非流水线方式，是客户在收到前一个响应后才能发起下一个请求

2.10.2 错误响应码

在HTTP/1.1中，新增了24个错误状态响应码，如：

• 409：表示请求的资源与资源的当前状态发生冲突
• 410：表示服务器上的某个资源被永久性地删除

2.10.3 缓存处理

HTTP/1.0中主要使用请求头中的If-Modified-Since、Expires来作为缓存判断的标准

HTTP/1.1中引入了更多的缓存控制策略，如强缓存和协商缓存，支持断点传输，以及增加了Host字段（使得一个服务器能够用来创建多个Web站点）如Entity tag、If-Unmodified-Since、If-Match、If-Node-Match等

2.10.4 带宽的优化以及网络连接的使用

HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象传送了进来，并且不支持断点续传等功能；

HTTP/1.1中，在请求头引入了range头域，它允许只请求资源的某个部分，即返回码为206（Partial Content），这样方便开发者自由的选择，以便于充分利用带宽和连接。

2.11 Cookie和Session

HTTP是一种无状态的协议，服务端不会保留与客户端通信时的任何状态。这样做的目的也是为了减轻服务端的记忆负担，使得服务端能够快速处理大量的事务，提高效率。

然而，在许多应用场景中，我们需要保持用户登录的状态或记录用户购物车中的商品。由于HTTP是无状态协议，所以必须引入一些技术来记录管理状态，如Cookie。

2.11.1 Cookie

Cookie指的是浏览器里面能够永久存储的一种数据。

Cookie由服务器生成，发送给浏览器并保存在本地的小型文本数据。浏览器下一次访问相同服务器时，会在请求头中携带cookie发送到服务器上。

1. 首次请求：浏览器第一次发送请求到服务器；
2. 响应：服务器对浏览器给出响应，创建并通过响应头 Set-Cookie 将 Cookie 发送给浏览器，Cookie的内存为要保存的数据；
3. 存储：浏览器接收到响应后会将 Cookie 中的数据存储在文件或内存中，并给Cookie一个有效期；
4. 携带：当浏览器再次向服务器发送请求时，会通过请求头将 Cookie 传递给服务器；
5. 获取：服务器解析收到的Cookie，然后给出响应。

2.11.1.1 Cookie作用

1. 服务端识别客户端身份
2. 记录历史

2.11.1.2 Cookie常见属性

Cookie 是一段不超过 4KB 的小型文本数据，由一个名称（Name）、一个值（Value）和其它几个用于控制 Cookie 有效期、安全性、使用范围的可选属性组成。

2.11.1.3 Cookie存储类型

1. Session Cookie：会话Cookie是存放在客户端的浏览器内存中的，只在当前会话有效，在用户关闭会话页或者关闭浏览器时就销毁。
2. Permanent Cookie：持久化Cookie是存放在客户端的硬盘中的，超过过期时间或者用户在网页中点击“注销”等按钮才会失效。

2.11.1.4 Cookie的特点

1. Cookie只存储在客户端，安全性低，一般用于存储少量的不敏感的信息
2. Cookie只能存储字符串，想存储其他类型的数据，需要将其转换成字符串
3. Cookie方便与JS交换数据，方便获取用户信息
4. Cookie遵循同源策略，不能跨域访问，除非特别部署
5. 浏览器对单个Cookie大小有限制（4KB），并对统一域名下的Cookie总数量也有限制（20个）
6. 浏览器可能会禁用Cookie

2.11.2 Session

由于Cookie存储在客户端，安全性低，我们希望登录状态这些数据能存储在服务端，于是就有了Session。

Session，会话，指客户端与服务端进行通信的过程。比如用户在浏览器中点击一个超链接访问Web资源，到关闭该标签页就是一个Session过程。

1. 客户端第一次请求服务器时，提交用户名和密码等信息进行登录认证，服务器根据客户端提交的信息进行鉴权。鉴权成功后，创建Session对象，用来保存相关数据，如用户角色、登录时间等。
2. 服务器响应时，将此Session的唯一标识信息SessionID返回给客户端。客户端收到后，将此SessionID存入到Cookie中，同时Cookie记录此SessionID属于哪个域名。
3. 客户端之后的每次请求，浏览器都会将当前域名下的Cookie信息发送给服务器
4. 服务器解析Cookie，获取到SessionID，查找与之对应的Session对象。
   • 如果Session对象存在则说明用户已经登录，返回请求数据。
   • 如果Session对象不存在或者已过期，则展示错误信息，并返回登录界面。

2.11.2.1 Session的特点

1. Sessio是服务端保存数据的一种机制，用户的一些关键信息会保存在Session中
2. Session可以保存在文件、数据库、内存中
3. 每个用户对应一个独立的Session，服务端会存储很多Session
4. 每个Session都有自己唯一的SessionID，用于标识客户端
5. Session都有过期时间，如果一定时间没更新数据，就会消失。

2.11.3 Cookie和Session的区别