Stateless application layer protocol of HTTP, i.e. HyperText Transfer Protocol, is an application layer protocol, which is based on a request and a response mode, often based on the TCP connection, the HTTP1.1 version, presents a continuing the connection mechanism -keep-alive, the vast majority of web development is a web application build on top of the HTTP protocol.
The main features of the HTTP protocol can be summarized as follows:
(1) support client / server model.
HTTP protocol work in the above client / server architecture, the browser as an HTTP client to the HTTP server by url, i.e. to send all requests a web server, a web server according to the received request, transmits the response information to the client.
(2) simple and fast
client to the server requests the service, simply transfer request method and path. Request method commonly used GET, HEAD, POST, each method provides different types of clients to contact the server. Due to the simple HTTP protocol, HTTP server makes the program a small scale, so the communication is very fast.
(3) Flexible
HTTP allows the transmission of any type of data object. It is the type of transmission being indicated by content-type.
(4) No connection
meaning no connection is to limit the processing only one request per connection, a client server processes the request and received the response, after the customer, i.e. disconnected, in this way can save transmission time, from HTTP1 from .1, long connection is used by default, i.e., the server must wait a certain time before disconnect, to ensure connection characteristics. Although some of the current technology, such as keep alive, long connection to optimize the efficiency of use, but these are part of the HTTP request other than, say, in each individual HTTP request, you can not know whether in the current HTTP state long connection, you always have to think that at the end of the HTTP request, the connection will be closed, which is the nature of HTTP, as to whether the underlying achieve closes the connection after the request, will not change this feature. Long connection may understand transparent lower layer of the upper layer.
(5) stateless
HTTP protocol is stateless protocol is stateless protocol for transaction processing means no memory capability, the lack of state means that, if the subsequent processing required in front of the information, it must be retransmitted, which may result in transmission for each connection the amount of data increases, on the other hand, when the server does not need previous information, it can quickly response.
HTTP protocol is currently in the case of multiple versions coexist, 1.0, 1.1 includes a wide range of mainstream is still the most widely used, as well as application of minimum, maximum Niubi blow 2.0.1.1 compared to 1.0, the most obvious difference is the introduction of the keep alive this long connection technology. 2.0 Although more rational, more advanced, but the promotion is not open due to the 1.1 fully able to meet the current application, and cost too much to upgrade to 2.0 due.
HTTP request structure
capture the following information obtained by wireshark:
HTTP Response structure
and wireshark capture, the following information
Step request / response :
(1) client to connect to the web server.
An HTTP client, typically a browser and the web server's HTTP port (default port number is 80) to establish a TCP socket connection.
(2) sending an HTTP request.
I.e., by sending a text TCP socket client request packet to the web server.
(3) accept the request and returns a server HTTP response.
web server parses the request, the resource location request, the server writes a copy TCP socket resources, read by the client.
(4) to release the TCP connection
if our connection mode to close, the server closes a TCP connection, the client passive close the connection, the release of a TCP connection. If we connection mode is keep alive, then the connection will be maintained for a period of time, you can continue to receive requests in the time.
(5) The client browser parses the HTML content
client browser First to resolve the status line to see that the request is successful status code, and then parses each response headers, response headers to inform the number of bytes of HTML documents and documents character set, the client browser reads the HTML response data, based on the HTML syntax, format it, and displayed in a browser window.
在浏览器地址键入URL，按下回车之后经历的流程：
（1）DNS解析
首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL中的域名对应的IP地址，DNS缓存从近到远依次是浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，从哪个缓存找到对应的IP，则直接返回，不再查询后面的缓存。
（2）TCP连接
找到IP地址之后，会根据IP地址及对应端口（默认80端口）和服务器建立TCP连接（三次握手）。
（3）发送HTTP请求
接着浏览器会发出读取文件的HTTP请求，该请求将发送给服务器。
（4）服务器处理请求并返回HTTP报文
服务器对浏览器请求做出响应，并把对应的带有HTML文本的HTTP响应报文发送给浏览器。
（5）浏览器解析渲染页面
之后，浏览器收到HTML，并在显示窗口去渲染它。
（6）连接结束
最后浏览器释放TCP连接（四次挥手）
HTTP状态码
五种可能的取值
（1）1xx：指示信息------表示请求已接收，继续处理
（2）2xx：成功-----------表示请求已被成功接收，理解，接收
（3）3xx：重定向---------要完成请求必须进行更进一步的操作
（4）4xx：客户端错误----请求有语法错误或请求无法实现
（5）5xx：服务器端错误–服务器未能实现合法的请求
GET请求和POST请求的区别：
从三个层面来解答
（1）HTTP报文层面：GET将请求信息放在URL，POST放在报文体中。
GET将请求信息放在URL后面，请求信息与URL以问号隔开，请求信息的格式为键值对。而POST请求方式将请求信息放在报文体中，想获得请求信息，必须解析报文，因此安全方式较GET方式要更高一些。事实上要获得报文体中的请求信息也是很容易的，因此安全性上两者并没有太大的区别。具体解决传输过程中的安全问题，还要靠HTTPS。
（2）数据库层面：GET符合幂等性和安全性，POST不符合。
幂等性就是对数据库的一次操作和多次操作的结果是一样的，安全性就是对数据库的操作没有改变数据库中的数据。GET请求做查询操作，因此不会改变数据库中原有的数据，大致可以认为是符合安全性和幂等性的。而POST请求是既不幂等又不安全的，首先POST请求会往数据库中提交数据，因此会改变数据库中的数据，其次，POST请求方式每次获得的结果都有可能不一样，因为POST请求是作用在上一级URL上的，则每一次请求都会添加一份新资源。
（3）其他层面：GET可以被缓存，被存储，而POST不行。
GET请求会被保存在浏览器的浏览记录中，因为GET请求的url能够保存为浏览器书签，而POST方式不具备上述功能。缓存也是GET请求被广泛应用的根本。
在现代网络上，每天产生的请求数目是巨大的，其中绝大部分请求为只读请求，如果所有这些请求都要交由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的设置以及发送过程：
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将会在本次响应中会回发给客户端进行保存。
There are two implementations Session
(1) use the cookie to achieve
a server assigned to each session a JSESSIONID, and sent to the client by a cookie, when the client initiates a new request, carrying the head in a cookie JSESSIONID, so that the server can find the client the corresponding session.
(2) write-back using the URL to achieve
URL is written back to the server refers to all links to the browser page, carries JSESSIONID parameters, so that the client click on any link they will take JSESSIONID back to the server. If the URL directly in the browser and enter the server resources to the resource request, then the session is not a match, tomcat session is to achieve at the same time use a cookie and start url write-back mechanism, if it is found the client cookie support, to continue use cookie, stop using the URL write back if you find cookie is disabled, has been using url write back.
Whether you use session url or write back, and they have a parameter called JSESSIONID is closely related to the JSESSIONID it maintains the mapping between the server with client requests and responses.
What is the difference between Cookie and Session?
(1) Cookie data is stored on the customer's browser, Session data is stored on the server,
(2) with respect to the Session Cookie safer.
(3) reduce the burden on the server, if considered, should use Cookie. session will be saved in a certain time on the server when accessing the increase, it would be more take up server performance, taking into account to reduce the cost of server performance, you should use cookie.