【从面试出发学习java】-网络 - HTTP简介

HTTP 原理

HTTP 是一个无状态的协议。无状态是指客户机（Web 浏览器）和服务器之间不需要建立持久的连接， 这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP 遵循请求(Request)/应答(Response)模型。客户机（浏览器）向服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答

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

1. 支持客户/服务器模式 C/S模式
   HTTP协议工作于客户端/服务端架构之上，浏览器作为HTTP与客户端通过URL向HTTP服务端即Web服务器发送所有请求。Web服务器根据接收到的请求向客户端发送响应信息。
2. 简单快速
   客户端向服务器请求服务的时候，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活
   HTTP允许传输任意类型的数据对象，正在传输的类型由Content Type加以标记
4. 无连接
   无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并受到客户的应答之后立即断开连接。采用这种方式可以节省传输时间。从HTTP1.1起，默认使用了长连接，即服务器需要等待一定的时间后才断开连接以保证连接特性。要始终认为HTTP请求完就立即关闭。
5. 无状态
   无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息则必须被重传。

地址解析
如用客户端浏览器请求这个页面：http://localhost.com:8080/index.htm 从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
协议名：http
主机名：localhost.com
端口：8080
对象路径：/index.htm
在这一步，需要域名系统 DNS 解析域名 localhost.com,得主机的 IP 地址。

HTTP请求结构

HTTP响应结构

请求/响应的步骤

1. 客户端连接到Web服务器
   一个HTTP客户端通常是浏览器与Web服务器的HTTP端口，默认端口号是80，建立一个TCP套接字连接。
2. 发送HTTP请求
   即通过TCP套接字，客户端通过服务器发送一个文本的请求报文
3. 服务器接收请求并返回HTTP响应
   Web服务器解析该请求，定位请求资源，服务器将资源副本写到TCP套接字，由客户端读取
4. 释放连接TCP连接
   若连接模式为CLOSE，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接
   若连接模式为Keep_Alive，则该连接会保持一段时间，在该时间内可以继续接收请求
5. 客户端浏览器解析HTML内容
   客户端首先解析状态行，查看表明请求是否成功的状态代码，然后解析每个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法，对其进行格式化，并在浏览器窗口中显示

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

1. DNS解析
   首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL中的域名所对应的IP地址。DNS缓存从近到远依次是浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存和域名服务器缓存、顶级域名服务器缓存。从哪个缓存找到对应的IP则直接返回不再查询后面的缓存
2. TCP连接
   找到IP地址之后，会根据IP地址和对应端口（默认80）和服务器建立TCP连接，这里可以结合三次握手
3. 发送HTTP请求
   浏览器会发出读取文件的HTTP请求，该请求将发送给服务器
4. 服务器处理请求并返回HTTP报文
   服务器对浏览器请求作出响应，并把对应的带有HTTP文本的HTTP响应报文发送给浏览器
5. 浏览器解析渲染页面
   浏览器收到HTML并在显示窗口内渲染
6. 连接结束
   浏览器释放TCP连接，该步骤即四次挥手，第5步和第6步可以认为是同时发生的，哪一步在前没有特别的要求

说说常见的HTTP状态码？

消息响应
100 Continue(继续)
101 Switching Protocol(切换协议)
成功响应
200 OK(成功)
201 Created(已创建)
202 Accepted(已创建)
203 Non-Authoritative Information(未授权信息)
204 No Content(无内容)
205 Reset Content(重置内容) 2
06 Partial Content(部分内容)
重定向
300 Multiple Choice(多种选择)
301 Moved Permanently(永久移动)
302 Found(临时移动)
303 See Other(查看其他位置)
304 Not Modified(未修改)
305 Use Proxy(使用代理)
306 unused(未使用)
307 Temporary Redirect(临时重定向)
308 Permanent Redirect(永久重定向)
客户端错误
400 Bad Request(错误请求)
401 Unauthorized(未授权)
402 Payment Required(需要付款)
403 Forbidden(禁止访问)
404 Not Found(未找到)
405 Method Not Allowed(不允许使用该方法)
406 Not Acceptable(无法接受)
407 Proxy Authentication Required(要求代理身份验证)
408 Request Timeout(请求超时)
409 Conflict(冲突)
410 Gone(已失效)
411 Length Required(需要内容长度头)
412 Precondition Failed(预处理失败)
413 Request Entity Too Large(请求实体过长)
414 Request-URI Too Long(请求网址过长)
415 Unsupported Media Type(媒体类型不支持)
416 Requested Range Not Satisfiable(请求范围不合要求)
417 Expectation Failed(预期结果失败)
服务器端错误
500 Internal Server Error(内部服务器错误)
501 Implemented(未实现)
502 Bad Gateway(网关错误)
503 Service Unavailable(服务不可用)
504 Gateway Timeout (网关超时)
505 HTTP Version Not Supported(HTTP 版本不受支持)

GET请求和POST请求的区别

从三个层面来解答：
从HTTP报文层面：
GET将请求信息放在URL后，请求信息和URL之间以？隔开，请求信息的格式为键值对。有长度限制。
POST请求方式则将请求信息放在报文体中，想获得请求信息必须解析报文，因此安全性较GET要高一些。事实上要获得报文体的请求信息也是很容易的，因此安全性上两者并没有明显的区别。具体解决传输过程中的安全问题还要靠HTTPS。数据长度没有限制

数据库层面：
GET请求方式符合幂等性（对数据库的一次操作和多次操作获得的结果是一致的）和安全性（对数据库的操作没有改变数据库的数据）。GET请求时做查询操作的，因此不会改变数据库中原有的数据。
POST请求是既不符合幂等性也不符合安全性。首先POST请求方式会往数据库中提交数据，因此会改变数据库中的数据；其次POST请求方式每次获得的结果都有可能不一样，因为POST请求是作用在上一级的URL上，则每一次请求都会添加一次新资源，这也是POST和PUT的最大区别。PUT的方式是幂等的

从其他层面来看：
GET请求能够被缓存，GET请求会保存在浏览器的浏览记录中，GET请求的URL能保存为浏览器书签
POST请求方式不具备上述功能。是非幂等的，必须交由服务器处理
缓存也是GET请求被广泛应用的根本。

Cookie和Session的区别

因为HTTP是无状态的，也就意味着每次访问某个有登录需求的页面之后，都需要输入账号密码。现实中并没有出现这样的情况是因为引入了让HTTP具备状态的机制，其中的两个便是Cookie和Session。
Cookie简介
Cookie是客户端的解决方案
Cookie是由服务器发送给客户端的特殊信息，而这些信息以文本文件的形式存放在客户端，然后客户端每次向服务器发送请求的时候，都会带上这些特殊的信息。更具体来将，当用户使用浏览器访问一个支持Cookie网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器，紧接着服务器在向客户端回传相应的超文本的同时也会发回这些个人信息。当然这些信息并不是存放在HTTP响应体，即Response Body中的，而是存放在HTTP响应头即Response Header。当用户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息，存放在一个统一的位置
在这里，客户端再向服务器发送请求的时候，都会把Cookie发回服务器中，而这一次Cookie信息则存放在HTTP请求头里面了
有了Cookie，服务器在接收到来自客户端的请求之后，就能够通过解析Cookie得到客户端特有的信息从而动态生成与该客户端相对应的内容。通常可以从很多网站的登录界面中，看到“请记住我”这样的选项，如果勾选该选项，那么在下一次访问该网站的时候，就不需要重复而繁琐的登录动作了。这个功能就是通过Cookie来实现的。

Cookie的设置和发送过程分为四步：

1. 客户端发送一个HTTP请求到服务端
2. 服务端发送一个HTTP Response到客户端，其中包含Set-Cookie的头部
3. 客户端发送一个HTTP请求到服务端，包括了Cookie头部
4. 此时服务器端发送一个HTTP响应到客户端
   

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

Session的实现方式

1. 使用Cookie来实现，服务器给每个Session分配一个唯一的J session id，并通过Cookie发送给客户端。当客户端发起新的请求时，将在Cookie头中携带这个J session id，这样服务器能够找到客户端对应的session
2. 使用URL回写来实现，URL回写是指服务器在发送给浏览器页面的所有链接中都携带J session id的参数。这个客户端点击任何一个链接，都会把J session id带回，如果服务器。如果直接在浏览器输出服务端资源的URL来请求该资源，那么session是匹配不到的。tomcat对session的实现是一开始同时使用cookie和URL回写机制，如果发现客户端支持cookie，就使用cookie停止使用URL回写发现cookie被禁用，就一直使用URL回写

Cookie和Session的区别是：

1. Cookie数据存放在客户的浏览器上，Session数据则存放在服务器上
2. Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗。考虑到安全应当使用Session
3. Session会在一定时间内保存在服务器上，当访问曾多会比较占用服务器的性能。考虑到减轻服务器性能的开销，应该使用Cookie