http

http - 浏览器和服务器交互的超文本传输协议
https - http + ssl (建安全通道,确保数据传输，网站真实性)
http 80 身份容易被伪装 内容容易被篡改窃取 收集流动的数据包且解析，可以交给抓包工具
Https 443 需证书费用高 对传输内容进行加密 身份认证 费时费电 保证数据安全送达 一个ip只能绑定一个域名

1. https链接访问
2. 服务器将授权证书的公开钥匙返回给客户端
3. 协商 SSL 链接加密等级
4. 按照加密等级，建立会话密钥
5. 然后通过网站的公钥来加密会话密钥
6. 服务器用私钥解开会话秘钥

ssl（secure socket layer 安全套接层）
tls（transport layer security）
SSL证书安全等级主要是受到SSL证书验证等级的影响，验证等级越高，那么安全等级也就越高。按验证等级可以分为三类：
DV SSL证书：只验证网站的域名所有权，此类证书仅能起到对网站数据加密的作用，无法向用户证明网站的真实性
OV SSL证书：在dv纸上，还能向用户证明网站的真实性，
EV SSL证书：提供权威的第三方担保进行验证。部署了EV SSL证书的网站，还会在浏览器地址栏显示绿色的公司名称，保障网站基本安全的同时还有利于提升公司品牌形象，比较适合政务. 金融. 电商等网站。

状态码302，301，304

1. 301 Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替
2. 302 Found 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有URI
3. 304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

http各个版本区别

1. http0.9 只能使用基本的get请求 请求完了就断开tcp链接
2. http1.0 get post HEAD 也是短连接
3. http1.1 put push delete 长链接 管道化 主流版本 etag
4. http2.0 长链接 多路复用 websoket

http请求方法get和post

1. GET在浏览器回退不会再次请求，POST会再次提交请求
2. GET请求会被浏览器主动缓存，POST不会，要手动设置
3. GET请求参数会被完整保留在浏览器历史记录里，POST中的参数不会
4. GET请求在URL中传送的参数是有长度限制的，而POST没有限制
5. GET参数通过URL传递，POST放在Request body中
6. GET参数暴露在地址栏不安全，POST放在报文内部更安全
7. GET一般用于查询信息，POST一般用于提交某种信息进行某些修改操作
8. GET产生一个TCP数据包；POST产生两个TCP数据包
9. GET - 从指定的资源请求数据。
10. POST - 向指定的资源提交要被处理的数据。
11. GET：不同的浏览器和服务器不同，一般限制在 2~8K 之间，更加常见的是 1k 以内。
12. GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
13. 对于 GET 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200
14. （返回数据）；
15. 而对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服
16. 务器响应 200 ok（返回数据）

其他其中方法

1. GET方法 发送一个请求来取得服务器上的某一资源
2. POST方法 向URL指定的资源提交数据或附加新的数据
3. PUT方法 跟POST方法很像，也是想服务器提交数据。但是，它们之间有不同。PUT指定了资源在服务器上的位置，而POST没有
4. HEAD方法 只请求页面的首部
5. DELETE方法 删除服务器上的某资源
6. OPTIONS方法 它用于获取当前URL所支持的方法。如果请求成功，会有一个Allow的头包含类似“GET,POST”这样的信息
7. TRACE方法 TRACE方法被用于激发一个远程的，应用层的请求消息回路
8. CONNECT方法 把请求连接转换到透明的TCP/IP通道

tcp和udp的区别

1. TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。
2. 虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为
3. 对数据准确性要求高，速度可以相对较慢的，可以选用TCP

区别	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

tcp三次握手，四次挥手

1. 客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西；
2. 由于TCP不存在连接的概念，只存在请求和响应，请求和响应都是数据包，它们之间都是经过由TCP创建的一个从客户端发起，服务器接收的类似连接的通道，这个连接可以一直保持，http请求是在这个连接的基础上发送的；
3. 在一个TCP连接上是可以发送多个http请求的，不同的版本这个模式不一样。
4. 在HTTP/1.0中这个TCP连接是在http请求创建的时候同步创建的，http请求发送到服务器端，服务器端响应了之后，这个TCP连接就关闭了；
5. HTTP/1.1中可以以某种方式声明这个连接一直保持，一个请求传输完之后，另一个请求可以接着传输。
6. 这样的好处是：在创建一个TCP连接的过程中需要“三次握手”的消耗，“三次握手”代表有三次网络传输。
7. 如果TCP连接保持，第二个请求发送就没有这“三次握手”的消耗。

三次握手

1. 刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后第一次握手，客户端向服务端发送连接请求报文,报文头部有SYN=1，ACK=0 (连接请求报文)，seq=x (TCP通信的字节流的初始序号)。请求发送后，客户端便进入SYN-SENT状态。服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
2. 第二次握手，服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1(连接同意的应答报文)，seq=y(服务端字节流的初始序号)，ack=x+1(服务端希望下一个数据报发送序号从x+1开始的字节)。 该应答发送完成后便进入SYN-RCVD状态。客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
3. 第三次握手，当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。 该报文段的头部为：ACK=1，seq=x+1，ack=y+1。 客户端发完这个报文段后便进入 establised状态，服务端收到这个应答后也进入 establised状态，此时连接的建立完成！服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常
   

握手问题

1. tcp字节流初始序号 是固定的吗
   三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。
   如果ISN是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。
2. 什么是半连接队列
   服务器第一次收到客户端的 SYN 之后，处于SYN_RCVD 状态，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
   已经完成三次握手，建立起连接的就会放在全连接队列中。
   SYN-ACK 重传次数的问题：　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超 过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s, 2s, 4s, 8s, …
3. 三次握手过程中可以携带数据吗
   第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。
   假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。
   而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。

四次挥手

1. 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
2. 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
3. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
   

挥手问题

1. 挥手为什么需要四次？因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
2. 为什么要2MSL等待状态？TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
3. 四次挥手释放连接时，等待2MSL的意义？MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。