计算机网络复习------HTTP相关

超文本传输协议HTTP主要特点

属于应用层协议，它是基于请求与响应模式的无状态应用层的协议，常基于TCP的连接方式。

HTTP1.1版本中给出一种持续连接的机制 KeepAlive,绝大多数的web开发，都是构建在http协议之上web应用

支持客户/服务器模式

HTTP协议工作于客户端服务端架构之上。浏览器作为HTTP客户端，通过URL向HTTP服务端及WEB服务器，发送所有请求。 web服务器根据接收到的请求向客户端发送响应信息。

简单快速

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

灵活

HTTP允许传输任意类型的数据对象，正在传输的类型由Content-Type加以标记。

无连接

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

 

从HTTP1.1起默认使用了长连接，即服务区需要等待一定时间后才断开连接，以保证连接特性

虽然目前的一些技术 如 KeepAlive 使用了长连接优化效率，但这些都是属于HTTP请求之外的。也就是说，在每个独立的HTTP请求中，我们是无法知道，HTTP是否处于长连接状态。这会让我们始终认为HTTP请求在结束后，连接就会关闭。

这是HTTP的特性，至于下沉实现是否在结束请求后关闭连接都不会改变这个特性。

长连接可以理解为下层实现对上层透明

 

无状态

HTTP协议是无状态协议，无状态协议是指协议对事务处理没有记忆能力，缺少状态意味着后续处理需要前段信息，则必须被重传。这样可以能导致每次连接的数据量增大。另一方面在服务器不需要先前信息时，它的应答就较快。

HTTP协议目前正处于多个版本共存的情况，包括仍被广泛采用的1.0，主流最为广泛的1.1。还有应用较少的2.0

1.1相较1.0最明显的区别就是引入了KeppAlive这项长连接技术。2.0虽然更合理更先进，但是其推广不开的原因也就是因为1.1完全能够满足目前的应用。并且升级上2.0成本太大所导致的。

HTTP请求结构

HTTP请求结构由HTTP请求报文，请求行，请求头部，请求正文4个部分组成

请求行 包括3个部分

请求方法 请求方法是常见的POST,GET,PUSH等等

URL

协议版本号  比如HTTP 1.0 HTTP 1.1

请求头部  是由若干个报头组成的，每个报头都是名字加分号，再加空格，再加值的形式。名字是大小写无关的，这些报头用来设置HTTP请求的一些参数。例如HOST表示被请求资源的主机和端口号。

请求正文  就是数据体，请求的数据。这个数据体只在POST请求用到，表示要上传的数据，数据体和头部之间是有个空行的，请求头部后面的空号是必须的，即第四部分的请求数据为空，也必须有空行。浏览器发送一个空白行来通知服务器，它已经结束了头信息的发送。

 

HTTP响应报文

发送报文后，正常情况下能收到其响应报文。服务器接收并处理客户端发过来的请求后，会返回一个HTTP响应消息。

响应报文主要包括3个部分 状态行，响应头部，响应正文。

状态行 主要有协议版本，状态码，状态码描述。

响应头部  说明客户端要使用的一些附加信息 

 

HTTP协议采用了请求响应模型，客户端向服务器发送了一个请求报文，请求报文包含请求方法，url,协议版本，请求头部和请求数据。

服务器以一个状态行作为响应，响应的内容包括协议的版本，成功或者错误代码，服务器信息，响应头部和响应数据。

 

HTTP请求/响应的步骤

客户端连接到WEB服务器

一个HTTP客户端通常以一个浏览器与WEB服务器HTTP端口，默认端口号是80，建立一个TCP套接字连接。

发送HTTP请求

通过TCP套接字，客户端向WEB服务器发送一个文本的请求报文

服务器接受请求并且返回HTTP响应

之后服务器接收到客户端请求并且返回HTTP响应。WEB服务器解析该请求，定位请求资源，服务器将资源副本写到TCP套接字，由客户端读取。

释放TCP连接

如果连接模式为Close,则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接。

如果连接模式为Keep Alive，则该连接会保持一段时间，在该时间内可以继续接收请求。

客户端浏览器解析HTML内容

客户端浏览器首先去解析状态行，查看表明请求是否成功的状态代码，然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集，客户端浏览器读取响应数据HTML，根据HTML的语法，类型进行格式化，并在浏览器窗口中进行显示。

 

在浏览器地址栏输入URL，按下回车之后经历的流程

DNS解析

浏览器会依据URL逐层查询DNS服务器缓存解析url中的域名所对应的IP地址。

DNS缓存从近到远依次是：浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存。

从哪个缓存找到对应的IP地址，则直接返回，不再查询后面的缓存

TCP连接

找到IP地址之后，会根据IP地址和对应的端口，默认是80端口，和服务器建立TCP连接，过程有三次握手

发送HTTP请求

浏览器会发出读取文件的HTTP请求，该请求将发送给服务器。

服务器处理请求并返回HTTP报文

服务器被浏览器请求做出响应，并把带有HTML文本的HTTP响应报文发送给浏览器

浏览器解析渲染页面

浏览器收到HTML之后，并在显示窗口内区渲染它。

连接结束

浏览器释放TCP连接，过程是四次挥手

 

 

HTTP状态码

5种可能的取值

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

2XX：成功  表示请求已被成功接收，理解，接受

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

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

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

 

常见状态码

200 OK：正常返回信息

400 Bad Request：客户端请求有语法错误，不能被服务器所理解

401 Unauthorized：请求未经授权，这个状态码必须和WWW-Authenticcate 报头域一起使用

403 Forbidden：服务器收到请求，但是拒绝提供服务

404 Not Found：请求资源不存在，比如输入了错误的URL

500 Internal Server Error：服务器发生不可预期的错误

503 Server Unavailable：服务器当前部能处理客户端的请求，一段时间后可能恢复正常

 

GET请求和POST请求的区别

从三个层面来解答

HTTP报文层面：GET将请求信息放到URL,POST放在报文体中

GET请求方式将请求信息放到url后面，请求信息和url之间，以问号隔开，请求信息的格式为键值对。

POST请求方式将请求信息放置在报文体中，向获得请求信息必须解析报文，因此安全性相对于GET方式要高一些。

事实上要获得报文体的请求信息也是很容易的，因此安全性上，两者并没有太多的区别。具体解决传输过程中的安全性问题，还得依靠HTTPS。

由于GET的请求信息放置在URL中，因此是有长度限制的，因为URL本身是没有长度限制的。

POST中的请求信息是放置在报文体中，因此对数据长度是没有限制的。

从数据库层面看：GET符合幂性和安全性，POST不符合

幂等性就是对数据库的一次操作，和多次操作获得的结果是一致的，则符合幂等性。

安全性定义就是对数据库的操作没有改变数据库中的数据，则认为符合安全性

GET请求是做查询操作的，因此不会改变数据库中原有的数据，大致的可以认为符合幂等性和安全性的。

POST请求会往数据库提交数据，因此会改变数据库中的数据，其次POST请求获得的结果可能每一次都不一样，因为POST请求是作用在上一级的URL上的，则每一次请求都会添加一份新资源。

其他层面：GET可以被缓存，被存储，而POST不行

GET请求会保存在浏览器的浏览记录中，以GET请求的URL能够保存为浏览器的书签，缓存是GET请求广泛应用的根本。

POST方式不具备上述功能

在现代网络上每天产生的请求数目是巨大地，并且其中绝大部分请求均为只读请求，如果所有这些请求都要交由 Web 服务器直接处理，这无疑是巨大的资源浪费。从第二部分知道GET表达的是一种幂等的、安全的，它除了返回结果不应该会产生其它副作用，因此绝大部分GET请求（通常超过90%）都直接被CDN缓存了，这能大大减少 Web 服务器的负担。 而POST是非幂等的，有副作用的操作，所以必须交由 Web 服务器处理。

 

Cookie和Session的区别

因为HTTP是无状态的，也就意味着，我们每次访问某个有登录需求的页面的时候，都要不厌其烦地输入账号密码，现实生活中并没有出现这样的情况，这是因为咱们引入了某些机制，让HTTP具备了状态，其中的两个便是Cookie和Session。

 

Cookie简介

Cookie技术是客户端的解决方案。
（1）是由服务器发送给客户端的特殊信息，以文本的形式存放在客户端。
然后客户端每次向服务器发送请求的时候，都会带上这些特殊的信息。
具体点讲，当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息，并且提交至服务器，紧接着服务器在向客户端回传相应的超文本的同时，也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体中，而是存放在HTTP响应头中，当用户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置。
（2）客户端再次请求的时候，会把Cookie回发。
至此，客户端再向服务器发送请求的时候，都会把相应的cookie再次发回到服务器中，而这次cookie信息则存放在HTTP请求头里面了。
（3）服务器接收到后，会解析cookie生成与客户端相对应的内容。
有了cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的cookie，得到客户端特有的信息，从而动态生成与该客户端相对应得内容，通常我们可以从很多网站得登录界面看到“请记住我”这样得选项，如果你勾选了它，之后再登录，那么再下一次访问该网站得时候，就不用进行重复繁琐得登录动作了。

 

Cookie的设置以及发送过程：

1. 客户端发送一个HTTP 请求到服务端

2.服务端发送一个HTTP响应到客户端，其中包括set-Cookie的头部

3.客户端再发送一个 HTTP请求 和Cookie到服务器端

4.服务端HTTP响应到客户端

 

Session简介

（1）服务器端的机制，在服务器上保存的信息。
Session机制是一种服务器端的机制，服务器使用了一种类似于散列表的结构来保存信息。
（2）解析客户端请求并操作session id，按需保存状态信息。
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标志，称为session id，如果已包含session id，则说明，以前已经为此客户端创建过session，服务器就按照session id，把这个session检索出来使用，如果检索不到，就可能会新建一个。如果客户端请求不包含session id，则为此客户端创建一个session，并生成一个与此session相关的session id。session id的值应该是一个既不会重复，又不容易被找到规律的以防捏造的字符串，这个session id将会在本次响应中会回发给客户端进行保存。

Session的实现方式有两种
（1）使用cookie来实现
服务器给每个session分配一个JSESSIONID，并通过cookie发送给客户端，当客户端发起新的请求的时候，将在cookie头中携带这个JSESSIONID，这样服务器能够找到客户端对应的session。

（2）使用URL回写来实现
URL回写是指服务器在发送给浏览器页面的所有链接中，都携带JSESSIONID的参数，这样客户端点击任何一个链接，都会把JSESSIONID带回服务器。如果直接在浏览器输入服务端资源的URL来请求该资源，那么session是匹配不到的，tomcat对session的实现是一开始同时使用cookie和url回写机制，如果发现客户端支持cookie，就继续使用cookie，停止使用URL回写，如果发现cookie被禁用，就一直使用url回写。

不管是使用session还是url回写，它们都和一个叫JSESSIONID的参数息息相关，这个JSESSIONID就维护了服务器跟客户端请求和响应之间的映射关系。

Cookie和Session的区别是什么？
（1）Cookie数据存放在客户的浏览器上，Session数据存放在服务器上，
（2）Session相对于Cookie更安全。
（3）若考虑减轻服务器负担，应当使用Cookie。session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面的开销，应当使用cookie。