http协议与https协议+UDP协议和TCP协议+WebSocket协议下服务端主动去发送信息+对称加密与非对称加密+get和post请求方式区别详解

TCP和UDP协议是TCP/IP协议的核心。 在TCP/IP网络体系结构中，TCP（传输控制协议，Transport Control Protocol）、UDP（用户数据报协议，User Data Protocol）是传输层最重要的两种协议，为上层用户提供级别的通信可靠性。其中TCP提供IP环境下的数据可靠传输，它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送；而UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说，TCP对应的是可靠性要求高的应用，而UDP对应的则是可靠性要求低的应用。

tcp和udp的区别：
1.tcp保证数据的正确，udp可能掉包
2.tcp是流模式，udp是数据报模式
3.tcp保证数据的顺序，udp不保证
4.tcp面向连接，udp无连接

TCP和UDP最大的区别就是：TCP是面向连接的，UDP是无连接的。TCP协议和UDP协议各有所长、各有所短，适用于不同要求的通信环境。TCP协议和UDP协议之间的差别如下表所示。

在实际的使用中，TCP主要应用于文件传输精确性相对要求较高且不是很紧急的情景，比如电子邮件、远程登录等。有时在这些应用场景下即使丢失一两个字节也会造成不可挽回的错误，所以这些场景中一般都使用TCP传输协议。由于UDP可以提高传输效率，所以UDP被广泛应用于数据量大且精确性要求不高的数据传输，比如我们平常在网站上观看视频或者听音乐的时候应用的基本上都是UDP传输协议。 [5]

什么是通信协议?
通信协议是对计算机必须遵守的规则的描述，只有遵守这些规则，计算机之间才能进行通信。TCP/IP 是不同的通信协议的基础，HTTP协议只是通信协议的一种（即HTTP协议基于TCP/IP协议）。

什么是HTTP?
超文本传输协议（Hypertext Transfer Protocol，缩写 HTTP）旨在启用客户端和服务器之间的通信，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据（在传输层数据传输分tcp协议和upd协议两种，但一般依靠tcp协议进行数据传输），互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

什么是HTTPS？
​ HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL / TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

http与https详解

HTTPS的加密方式： HTTPS采用处理信息的方式是：结合对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。

  对称加密+非对称加密的方式过程：
   1、先使用非对称加密，得到公钥，再利用公钥生成一个传输密钥，进行双方的数据传输；
   2、client第一次请求，server给client返回公钥；
   3、client拿到公钥，再生成一个随机字符串，使用公钥对这个字符串进行加密，传给server；
   4、server收到后，用私钥解密出字符串，这个字符串用来作为之后双方进行数据传输的对称密钥
1
2
3
4
5

但是，这种加密的方式也并非万无一失，中间人可以截取了对称加密中的密钥，因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的,就像身份证一样，唯一标识我们服务器的公钥，解决这个问题的方式就是使用数字证书，具体是这样的：
我们需要一个在互联网世界中充当公理的机构来签发这个证书，它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了。
而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！
我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名：

总结HTTPS的加密方式：结合对称加密+非对称加密，但还要利用数字证书和数字签名
总结HTTP的加密方式：结合对称加密+非对称加密

HTTP的交互流程一般分为四个步骤（一次完整的请求）：
一：客户端和服务器端建立连接
二：客户端发送请求数据到服务器端（HTTP协议）
三：服务器端接受到请求后，进行处理，然后将处理结果响应客户端（HTTP协议）
四：关闭客户端和服务器端的链接（HTTP1.1后不会立即关闭）

HTTP协议的请求格式
请求格式的结构：
请求头：请求方式、请求的地址和HTTP协议版本
请求行：消息报头，一般用来说明客户端要使用的一些附加信息。
空行：位于请求行和请求数据之间，空行是必须的。
请求数据：非必须。

HTTP协议的请求方式
根据HTTP标准，HTTP请求可以使用多种请求方法。HTTP1.0定义了三种请求方法：GET、POST和HEAD方法。HTTP1.1新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE和CONNECT方法。
GET：请求指定的页面信息，并返回实体主体。
HEAD：类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。
POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件），数据被包含在请求体中。post请求可能会导致新的资源的建立和或已有资源的修改。
PUT：从客户端向服务器传送的数据取代指定的文档的内容。
DELETE：请求服务器删除指定的页面。
CONNECT：HTTP1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS：允许客户端查看服务器的性能。
TRACE：回显服务器收到的请求主要用于测试或者判断。

HTTP的方法
请求方式（常用6种）
get（常用的）请求从服务器获取特定资源。
post（常用的）用于将数据发送到服务器来创建/更新资源
delete（常用的）从服务器删除特定的资源。
put（常用的）用于将数据发送到服务器来创建/更新资源
head（常用的）：本质和get一样，但是响应中没有呈现数据，而是http的头信息，
options（常用的）：获取服务器支持的http请求方法，以及允许客户端查看服务器的性能，比如跨域中的预检请求（检测某个接口是否支持跨域。
trace：回显服务器收到的请求，主要用于测试或诊断。一般禁用，防止被恶意攻击或盗取信息
patch：更用于将数据发送到服务器来创建/更新资源，区别在于PATCH做部分更新，使用的比较少。
fetch：是一种HTTP数据请求的方式，是XMLHttpRequest的一种替代方案。fetch不是ajax的封装（其他方法是ajax的封装），没有使用XMLHttpRequest对象。

一个http请求,会进行三次握手建立tcp连接，关闭tcp连接需要4次挥手

三次握手（Three-way Handshake），是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。
4次挥手(TCP 是双向的，所以需要在两个方向分别关闭，每个方向的关闭又需要请求和确认，所以一共就4次)

三次握手：
1、浏览器需要先发送SYN码，客户端请求和服务器建立连接；
2、服务器接收到SYN码，再发送给客户端SYN+ACK码，我可以建立连接；
3、客户端接收到ACK码，验证这个ACK是否正确，如果正确则客户端和服务端则建立起数据连接；双方的数据发送通道都将开启

四次挥手：
1、TCP发送一个FIN，用来关闭客户到服务端的连接。
2、服务端收到这个FIN，他发回一个ACK，确认收到。
3、服务端发送一个FIN到客户端，服务端关闭客户端的连接。
4、客户端发送ACK报文确认，这样关闭完成。

http属于计算机网络的哪一层：HTTP协议和SMTP协议都属于应用层

get和post请求方式的区别：
GET在浏览器回退/刷新时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被书签收藏，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置（比如POST请求的响应设置了expires或者catch-control，那么浏览器会缓存这个POST请求的结果）。

任何一个get请求最终的“响应结果”都会被浏览器缓存起来。在浏览器缓存当中：
一个get请求的路径a对应一个资源。
一个get请求的路径b对应一个资源。
一个get请求的路径c对应一个资源。
....
实际上，你只要发送get请求，浏览器做的第一件事都是先从本地浏览器缓存中找，找不到的时候才会去服务器上获取。这种缓存机制目的是为了提高用户的体验。
有没有这样一个需求：我们不希望get请求走缓存，怎么办？怎么避免走缓存？我希望每一次这个get请求都去服务器上找资源，我不想从本地浏览器的缓存中取
只要每一次get请求的请求路径不同即可，即在路径后面加时间戳
1
2
3
4
5
6
7
8

编码类型：GET请求只能进行url编码（application/x-www-form-urlencoded），而POST支持多种编码方式
（application/x-www-form-urlencoded 或 multipart/form-data，可为二进制数据使用多种编码。）。

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET请求在URL中传送的参数是有长度限制的（因为浏览器对URL的长度有限制，最大长度是 2048 个字符），而POST没有。

对参数的数据类型的限制，GET只接受ASCII字符，而POST没有限制也允许二进制数据。

GET参数通过URL传递，参数之间以&相连，POST放在Request body中，所以GET请求相对不安全，敏感信息会暴露在url上。

为什么不能一味的认为get请求就是不安全呢？因为
get请求是绝对安全的，为什么？因为get请求只是为了从服务器上获取数据。不会对服务器造成威胁。
post请求是危险的。为什么？因为post请求是向服务器提交数据，如果这些数据通过后门的方式进入到服务器当中，服务器是很危险的。另外post是为了提交数据，所以一般情况下拦截请求的时候，大部分会选择拦截（监听）post请求。
1
2
3

GET和POST还有一个重大区别是发送数据包数量不同，GET 请求产生一个 TCP 数据包，而POST请求产生俩个 TCP 数据包，

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

**GET 请求过程：**
浏览器发起请求 TCP 连接（第一次握手）
服务器响应进行 TCP 连接（第二次握手）
浏览器确认，并发送 GET 请求头和数据（第三次握手）
服务器返回 200 OK响应

**POST 请求过程：**
浏览器发起请求 TCP 连接（第一次握手）
服务器响应进行 TCP 连接（第二次握手）
浏览器确认，并发送 POST 请求头（第三次握手）
服务器返回100 Continue响应
浏览器发送数据
服务器返回 200 OK响应

**GET和POST请求相同点**
从上面我们了解到HTTP协议是基于TCP/IP协议的一个子协议，所以GET 和 POST 请求的本质是相同的，都是TCP/IP请求。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

get和post请求相关知识参考链接

服务端不能主动去发送信息？http协议不能，WebSocket协议（双向通信）可以
有时候，我们希望服务端能够主动推送一些信息给客户端。但 HTTP 协议只能让客户端发起请求然后服务端响应，而无法让服务端主动去发送信息。
为了解决这个问题，我们有三种常见的解决方案：WebSocket协议（真正的使服务端主动去发送信息）、短轮询、长轮询（轮询只是在服务端设置达到需求而已，并不是服务端主动发送信息）。

WebSocket：
因为有服务端主动推送消息的需求，所以 WebSocket 协议出现了。
WebSocket 和 HTTP 协议一样，是应用层协议，上层也是依靠传输层的 TCP 协议进行数据传输。
不同的是，WebSocket 有完整的全双工能力，支持服务端主动推送，且具有较低的开销。在服务端推送比较重的应用中，比如聊天室，WebSocket 是不二人选。
浏览器建立 WebSocket 的过程：先发送 HTTP 请求，其中带上请求升级为 WebSocket 的相关头字段，服务端如果支持，就会返回 101 状态码，表示可以切换协议，建立好 WebSocket 连接。
之后浏览器就可以通过监听事件的方式获取服务端主动推送消息了。

总结：
短轮训的特点是实现简单，不需要太多改造工作。
长轮询会将 HTTP 请求挂起，直到状态变化时才返回数据给客户端，可以减少请求数量和带宽，但需要考虑意外关闭的情况，且实现复杂。
WebSocket 协议则是专门为了解决服务推送问题而发明的协议，能够真正实现服务端的主动推送，适合服务推送比较重的场景。
转载原文详解

对称加密与非对称加密的区别：对称加密中加密和解密使用的密钥是同一个（不分公钥和私钥）；非对称加密中采用两个密钥，分为公钥和私钥，一般使用公钥进行加密，私钥进行解密 (如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密)。2、对称加密解密的速度比较快，非对称加密和解密花费的时间长、速度相对较慢。3、对称加密的安全性相对较低，非对称加密的安全性较高。

http请求的headers中包含：http的headers称为消息头，里面包含general（基本信息），responseHeader（响应头），request header（请求头） —（这些都是headers中的属性，不是response返回的数据）

general中包含：
1.request rul ：请求的url
2.request methed：请求的方式
3:status code：响应码 （这个code不是指后端返回数据中的code，但属性值要是200就代表正常响应）
4：remote address：远程地址，包含ip和端口
5.Referrer Policy: 作用就是为了控制请求头中referer的内容(referer表示这个请求是从哪个URL过来的)

responseHeader（响应头），request header（请求头）详解点击此处

浏览器内核（Rendering Engine），是指浏览器最核心的部分，负责对网页语法的解释（如标准通用标记语言下的一个应用HTML、JavaScript）并渲染（显示）网页（即解析引擎和渲染引擎）

1.Gecko（Firefox内核），补充：具体JavaScript解析引擎是：JaegerMonkey（4.0）。

2.Webkit（Safari内核，Chrome内核原型，开源）:它是苹果公司自己的内核，也是苹果的Safari浏览器使用的内核，Webkit引擎包含WebCore排版 / 渲染引擎及JavaScriptCore解析引擎

3.Chrome浏览器内核（统称为Chromium内核或Chrome内核）：以前是Webkit内核，现在是Blink内核，具体的JavaScript解析引擎是v8，渲染引擎是开源引擎WebKit中WebCore组件的一个分支

4.Opera浏览器内核：最初是自己的Presto内核(已废弃)，后来是Webkit，现在是Blink内核，具体的JavaScript解析引擎是v8，渲染引擎是开源引擎WebKit中WebCore组件的一个分支， Opera浏览器是由挪威Opera Software ASA公司制作的

5.IE浏览器内核：Trident内核，IE8的JavaScript引擎是Jscript，IE9开始用Chakra

注：内核基本上都是开源的，所以很多浏览器都同用一种内核或双核

（OdlnMonkey是之前版本的解析引擎，现在是JaegerMonkey解析引擎）