HTTP本身是应用层协议，协议本身并不约束传输层用的啥。而HTTP是一个基于TCP的协议，TCP是一种可靠的传输层协议，有三次握手，四次挥手。

几个报文的标识的解释：SYN: synchronization(同步)、ACK: acknowledgement(确认:告知已收到)、FIN: finish(结束)

三次握手(three-way handshake)，建立TCP连接时会发生：
UserAgent > Server [SYN] 在么
Server > UserAgent [SYN, ACK] 在
UserAgent > Server [ACK] 知道了

四次挥手(four-way handshake)，关闭TCP连接时会发生：
UserAgent > Server [FIN] 我要关闭连接了
Server > UserAgent [ACK] 知道了,等我发完包先
Server > UserAgent [FIN] 我也关闭连接了
UserAgent > Server [ACK] 好的,知道了
其他：在HTTP/1.1中,keep-alive能够复用TCP连接,减少TCP三次握手的次数,从而提升性能.

在早期的HTTP/1.0中，每次http请求都要创建一个连接，而创建连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在后来的HTTP/1.0中以及HTTP/1.1中，引入了重用连接的机制，就是在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流。协议规定HTTP/1.0如果想要保持长连接，需要在请求头中加上Connection: keep-alive，而HTTP/1.1默认是支持长连接的，有没有这个请求头都行。当然了，协议是这样规定的，至于支不支持还得看服务器（比如tomcat）和客户端（比如浏览器）的具体实现。在实践过程中发现谷歌浏览器使用HTTP/1.1协议时请求头中总会带上Connection: keep-alive，另外通过httpclient使用HTTP/1.0协议去请求tomcat时，即使带上Connection: keep-alive请求头也保持不了长连接。一般服务端都会设置keep-alive超时时间。超过指定的时间间隔，服务端就会主动关闭连接。同时服务端还会设置一个参数叫最大请求数，比如当最大请求数是300时，只要请求次数超过300次，即使还没到超时时间，服务端也会主动关闭连接。

HTTP请求/响应报文

HTTP请求报文组成:请求行+请求头+请求体
HTTP响应报文组成:响应行+响应头+响应体
请求行: 请求方法(HEAD/GET/POST) + 请求URL + HTTP协议版本
响应行: HTTP协议版本 + 状态码 + 状态码描述
请求头: 比如客户端的Cookie和User-Agent就放在这里.
响应头: 比如服务器的Set-Cookie和Server信息就放在这里.
请求体: 比如客户端POST的数据就放在这里(对比:GET的数据放在请求行的URL里).
响应体: 比如服务器返回的HTML和JSON数据就放在这里.

HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。TCP有可靠，面向连接的特点。
如何理解HTTP协议是无状态的
　　HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

长连接、短连接

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：
Connection:keep-alive
　　在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

TCP连接

当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接 时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的

TCP短连接

我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server 发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起 close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在 client/server间传递一次读写操作
短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

TCP长连接

接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：
客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

长连接和短连接的优点和缺点

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
　　而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

HTTPS

​ 安全超文本传输协议(Secure Hypertext Transfer Protocol)，HTTPS实际上应用了Netscape的完全套接字层（SSL） 作为HTTP应用层的子层(HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信)，SSL使用40位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。

Http和Https区别

一、https协议需要到ca申请证书，一般免费证书很少，需要交费。
　　二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
　　三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
　　四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证、完整性保护，即HTTP+ 加密 + 认证 +完整性保护 = HTTPS，比http协议安全。

​ 五、HTTP的缺点：通信使用明文，内容可能被窃听；不验证通信方身份，有可能遭遇伪装(跨站点请求伪造)；无法证明报文的完整性，有可能已被篡改(运营商劫持)

POST和GET区别

• get是从服务器上获取数据，post是向服务器传送数据。
• get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
• get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
• get安全性非常低，post安全性较高。但是执行效率却比Post方法好。

为什么GET比POST更快？

• POST在真正接受数据之前会将请求头发送给服务器进行确认，然后浏览器才真正发送数据。
• 如果获取的是静态数据，chrome和firefox下会将数据缓存起来，而post不会，当然一般不会用post请求静态数据。

TCP与UDP的区别

​ 1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

​ 2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

​ 3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的，****UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速****率降低（对实时应用很有用，如IP电话，实时视频会议等）

​ 4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

​ 5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

​ 6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

一次完整的HTTP请求过程

​ 域名解析(DNS，万维网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）)

​ 发起TCP的3次握手

​ 建立TCP连接后发起http请求

​ 服务器响应http请求，浏览器得到html代码

​ 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）

​ 浏览器对页面进行渲染呈现给用户

其他

XSS攻击

XSS攻击全称跨站脚本攻击，是为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS，XSS是一种在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。XSS漏洞按照攻击利用手法的不同，有以下三种类型：

类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。

类型B，反射式漏洞，这种漏洞和类型A有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。

类型C，存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。

HttpOnly

我们知道http协议是无状态的，所以会在服务端生成一个cookie保存在客户端的浏览器中。这个cookie用以标识身份，而且可以直接从浏览器的document对象中获取到，对于某些关键的cooke是不安全的，使用HttpOnly可以让cookie在document中不可见，从而提高攻击的难度，但是HttpOnly并不是万能的，黑客仍然可以通过其他手段，比如socket抓包实施攻击。