• DNS域名解析：域名 -> IP地址
• 关于HTTP协议
• 常用的HTTP请求头与响应头
• HTTP协议是无状态的：每一次请求都是相互独立的

一、Http的特点：

1.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、PUT、DELETE、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2.灵活：HTTP允许传输任意类型的数据对象。

3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

4.无状态：HTTP协议是无状态的，HTTP 协议自身不对请求和响应之间的通信状态进行保存。任何两次请求之间都没有依赖关系。直观地说，就是每个请求都是独立的，与前面的请求和后面的请求都是没有直接联系的。协议本身并不保留之前一切的请求或 响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。

二、Http报文

Http报文包括请求报文和响应报文两大部分，其中请求报文由请求行（request line）、请求头（header）、空行和请求体四个部分组成。而响应报文由状态行、响应头部、空行和响应体四个部分组成。接下来我们详细介绍下请求报文的各个部分及其作用。

请求报文

1.请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本。

POST /chapter17/user.html HTTP/1.1

以上代码中“POST ”代表请求方法，“/chapter17/user.html”表示URI，“HTTP/1.1”代表协议和协议的版本。现在比较流行的是Http1.1版本

2.请求头由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。

请求头部通知服务器有关于客户端请求的信息。它包含许多有关的客户端环境和请求正文的有用信息。其中比如： Host，表示主机名，虚拟主机；Connection,HTTP/1.1增加的，使用keepalive，即持久连接，一个连接可以发多个请求；User-Agent，请求发出者，兼容性以及定制化需求。

3.最后一个请求头之后是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。

4.请求体，可以承载多个请求参数的数据

name=tom&password=1234&realName=tomson

上面代码，承载着name、password、realName三个请求参数。

三、HTTP请求方法

• GET 请求指定的页面信息，并返回实体主体。

• HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头

• POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。

• PUT 从客户端向服务器传送的数据取代指定的文档的内容。

• DELETE 请求服务器删除指定的页面。

五、Http状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

• 1xx：指示信息--表示请求已接收，继续处理

• 2xx：成功--表示请求已被成功接收、理解、接受

• 3xx：重定向--要完成请求必须进行更进一步的操作

• 4xx：客户端错误--请求有语法错误或请求无法实现

• 5xx：服务器端错误--服务器未能实现合法的请求

比如我们平时常见两种出错的状态码：
403 Forbidden //对被请求页面的访问被禁止
404 Not Found //请求资源不存在，比如：输入了错误的URL</pre>

六、持久连接

1.为什么需要持久连接

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着 HTTP 的 普及，文档中包含大量图片的情况多了起来。比如，使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请 求该 HTML 页面里包含的其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的 开销。

2.持久连接的特点

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外， 减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高了。 在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非 标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需 要支持持久连接。

七、管线化

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能 发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。 这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。通俗地讲，请求打包一次传输过去，响应打包一次传递回来。管线化的前提是在持久连接下。

视频讲解：

• 请求一个HTTP网页时，可能会产生多个HTTP请求：第一次请求是得到你请求的xml页面，当你的xml页面包含连接、图片时，会为链接、图片再发请求（ 只有文本时，只会有一次请求）
• 当一个网页的请求太多了时，会减慢网页相应速度，可以将用到的图片、样式合并，减少请求的次数

• 缓存中的过期事件设置的是一个具体的过期日期

  
  
• post的不安全是指对服务器的端的数据会产生修改，所以不具有幂等性；但是get请求有幂等性
• 注册用户用post，但是当对用户的数据进行修改时，应该使用普通方法
• get、post请求：

get一般用来获取服务器的数据，post一般用来向服务器端发送数据
get参数一般在URL中，post参数在请求的body中
get参数的数据最大为2kb，post理论是不受限制的（80kb）
get的执行效率比post要高，但是post相对来说要安全一些
get的请求会被浏览器主动的缓存，而post不会，除非手动设置
get请求只会产生一个包，而post会产生两个

• 常用的web服务器：

Apache:可以运行在Linux, Windows, Mac
IIS:是微软的软件，只能运行在Windows电脑上
NGINX:只能运行Linux/Unix

COOKIE和SESSION

Cookie

Cookie技术是客户端的解决方案：服务器在用户登陆后会按照一定规律生成的标志位，将这个标志发送给客户端，客户端存储此标志，以后请求带上此标志告诉服务器自己的身份。
cookie的内容主要包括：名字，值，过期时间，路径和域
客户端提交个人信息后，服务端返回数据的同时会在Response Header中返回Cookie信息，客户端保存在固定的位置（Set-Cookie： 设置返回的Cookie）
客户端在下次请求的时候会在Request Header中携带Cookie信息，服务端根据Cookie确认用户身份（如：自动登陆）（Cookie： 设置上传携带的Cookie）

cookie的设置以及发送过程分为以下四步：

1. 客户端发送一个http请求到服务器端
2. 服务器端发送一个http响应到客户端，其中包含Set-Cookie头部
3. 客户端发送一个http请求到服务器端，其中包含Cookie头部
4. 服务器端发送一个http响应到客户端

• Cookie有效期：由maxAge决定，在服务器返回cookie时已设置号对应的时间

  • 正数：表示有效期 时间为 maxAge，需；序列化在磁盘中，超过时间失效
  • 负数：临时Cookie 不序列化，保存在内存中，关闭浏览器失效
  • 0 ：表示删除该Cookie

• Cookie的修改、删除

  • 修改：创建同名的Cookie在Response中返回，覆盖原来的
  • 删除：创建同名的Cookie，设置maxAge = 0，在Response中返回

Session

Session技术是服务端的解决方案，通过服务器来保持状态；当客户端第一次请求时服务器首先检查这个客户端的请求里是否已包含了一个session标识，称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，发送给客户端，客户端储存，客户端再次发送请求的时候，会将这个Session id带上，服务器根据SessionID查找用户身份

• Session原理：服务端端每一个session维护一份会话信息数据，客户端和服务端依靠一个全局唯一标sesssion_id来访问会话信息数据
• Session创建：server端程序调用HttpServletRequest.getSession(true)这样的语句时才被创建
• session的保存：
  • Cookie：一般采用Cookie保存sessionId，这样下次请求时会自定添加到Request Header，cookie的名字都是类似于SEEESIONID，比如weblogic对于web应用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID
  • URL重写（cookie被禁止）：在客户端禁止Cookie时，Cookie就无法保存SessionId和发送了，此时可以使用其他方法解决：把sessionId直接附加在URL的路径之后：http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764； 作为字符串附加在请求中：http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
    与Cookie对比

1. cookie：信息保存在本地容易被第三方或其他获取，发起恶意请求
2. session：信息保存在服务端的内存中，本地只使用cookie保存sessionId

• sessionId的时效
  服务器会设置时间限定，当超过限定时间后还收不到客户端的请求即认为失效，session会结束生命周期，此时需要重新登陆
  没有储存在数据库的Session，会在服务器重启后失效
  用户退出登陆的时候会发起删除session，此时服务器会删除session
• 防止session混乱
  通过设置客户端的令牌来解决；在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了

Http缓存

（一）强缓存：

• Expires ：response header里的过期时间，浏览器再次加载资源时，如果在这个过期时间内，则命中强缓存。
• Cache-Control:当值设为max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。
  区别：Expires 是http1.0的产物，Cache-Control是http1.1的产物
  两者同时存在的话，Cache-Control优先级高于Expires
  Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法

（二）协商缓存：

• ETag和If-None-Match:
  Etag是上一次加载资源时，服务器返回的response header，是对该资源的一种唯一标识，只要资源有变化，Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里
  服务器接受到If-None-Match的值后，会拿来跟该资源文件的Etag值做比较，如果相同，则表示资源文件没有发生改变，命中协商缓存。
• Last-Modified和If-Modified-Since
  Last-Modified是该资源文件最后一次更改时间,服务器会在response header里返回
  同时浏览器会将这个值保存起来，下一次发送请求时，放到request headr里的If-Modified-Since里
  服务器在接收到后也会做对比，如果相同则命中协商缓存
  在精确度上，Etag要优于Last-Modified，Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度。在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
  在优先级上，服务器校验优先考虑Etag。
  所以，两者互补

浏览器缓存过程：

• 浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间(要与Cache-Control和Expires对比)一并缓存；
  下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过Cache-Control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用Expires判断是否过期）；
  如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since 的请求；
  服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回 200；
  如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回 200；