HTTP
1、HTTP是什么？
简单：超文本传输协议
传输：双向的
协议：规范与约定
超文本：包含图片、音频、视频等，不仅仅是文本
回答：HTTP是一个在计算机世界里专门在[两点]之间[传输]文字、图片、音频、视频等[超文本]数据的[协议和规范]
2、HTTP常见的状态码
五大类
1xx:属于提示信息，是协议处理中的一种中间状态
2xx:表示服务器成功处理了客户端的请求
200：表示一切正常
204：请求成功响应，没有资源返回
206：表示返回的body数据并不是资源的全部，而是其中的一部分
3xx:重定向
301：永久重定向，说明资源已经不存在，需改用新的URL再次访问
302：临时重定向，说明资源还存在，但暂时需要用另一个URL来访问
304：表示资源未修改，重定向已存在的缓存文件
4xx:客户端错误
400：请求报文存在语法错误
403：表示服务器禁止访问资源
404：表示请求的资源在服务器上找不到或不存在
5xx:服务端的错误
500：服务端在执行时发生错误
501：客户端请求的功能还不支持
502：表示服务器自身工作正常，访问后端服务器发生了错误
503：表示服务器暂时无法响应
3、HTTP常见字段有哪些？
1.Host
客户端发送请求时，用来指定服务器的域名
2.Content-Length字符
表明服务器本次回应的数据长度
3.Connection字符
常用于客户端要求服务器使用TCP持久连接，以便其他请求复用
Connection：keep-alive（一个可以复用TCP连接就建立了，直到客户端或服务器主动关闭连接）
4.Content-Type字段
用于服务器回应时，告诉客户端，本次数据是什么格式
（Accept：*
4、HTTP请求方法
1.GET：通常用来获取资源
2.POST：提交数据
3.PUT：修改数据
4.DELETE：删除数据
5.CONNECT：建立连接隧道
6.HEAD：获取资源的元信息
７.TRCACE：追踪请求
5、HTTP报文结构
具体而言：起始行+头部+空行+主体
由于http报文有请求报文和响应报文两类，因此分开介绍
1.起始行：对于请求报文而言，就是方法+路径+http版本，对于响应报文而言，就是http版本+状态码+原因三部分
2.头部：由首部字段名和值组成
3.空行：用来区分分开头部和实体
4.实体：就是具体的数据，body部分，分请求体和响应体。
6、get和post区别
get用来获取数据，而post用来上传数据
1）从缓存的角度：get请求会被浏览器缓存下来，留下历史记录，而post默认不会
2）从编码的角度：get只能进行URL编码，只能接受ASCII编码，而post没有限制
3）从参数的角度：get一般放在URL中，不安全，而post放在请求体中，可用来传输敏感信息
4）从幂等性角度：get是幂等的，post不是
5）从TCP的角度：get请求会把请求报文一次性发出去，而post会分为两个tcp数据包，首先发送header部分，如果服务器响应100，则再发body部分（火狐浏览器除外）
7、HTTP的优点和缺点
最突出的优点：简单、灵活、易扩展、应用广泛和跨平台
1.简单
HTTP基本的报文格式是header+body，头部信息也是key-value简单文本的形式，已于理解
2.灵活和易扩展
HTTP协议里的各类请求方法、URL/URI、状态码、头字段等每个组成要求都没固定死，允许开发人员自定义和扩展
3.应用广泛和跨平台
4.无状态：因此不需要额外的空间去存储
5.可靠传输
缺点：
1.无状态（双刃剑）
无状态：对于事务处理没有记忆能力
（1）好处：服务器不会去记忆HTTP的状态，所以不需要额外的资源来记录状态信息，这能减 轻服务器的负担
（2）坏处：由于对于事务处理没有记忆能力，则在完成有关联性的操作时会非常麻烦
（3）解决办法：使用Cookie（在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了）
2.明文传输（双刃剑）
明文：即没有加密
（1）好处：方便阅读
（2）坏处：HTTP所有信息都暴露了，在传输的漫长过程中，信息很容易被窃取
3.队头阻塞问题
当http开启长连接时，共用一个TCP链接，同一时刻只能处理一个请求， 如果该请求处理时间很长，其他请求只能处于阻塞状态
3.不安全
（1）使用明文传输：内容可能会被窃取
（2）不验证通信方的身份：有可能遭遇伪装（假淘宝，钓鱼网站）
（3）无法证明报文的完整性：有可能已遭篡改（网页上植入垃圾广告）
8、HTTP/1.1的性能
1.长连接
也叫持久连接，这种方式减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务端的负载。
其主要特点在于：只要任意一端没有明确提出断开连接，则保持TCP连接状态
2.管道网络传输
同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是，服务器的响应是按顺序的，如果前面的回应特别慢，后面就会有许多请求排队等待，这称为[对头阻塞]
3.队头阻塞
9、HTTP和HTTPS的区别
1.HTTP是超文本传输协议，信息是明文传输，存在安全风险问题。HTTPS解决了HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TSL安全协议，使得报文能够加密传输
2.HTTP连接建立相对简单，TCP三次握手之后便可进行报文传输。而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进行报文传输
3.HTTP端口号是80，HTTPS的端口号是443
4.HTTPS协议需要申请数字证书，来保证服务器的身份是可信的
10、HTTPS是如何解决HTTP不安全的问题
HTTPS并不是一个新的协议，它在HTTP和TCP的传输中建立了一个安全层，利用对称加密和非对称加密结合数字证书认证的方式，让传输过程的安全性大大提高。
１）对称加密：即加密和解密用的是同样的密钥
２）非对称加密：如果由A、B两把密钥，如果用A加密过的数据只能用B解密，反之，如果用B加密过的数据包只能用A解密。
３）证书：服务器向第三方认证机构（CA）获取授权，认证后CA给服务器发数字证书。服务器使用数字证书向浏览器证明自己的身份。
4）防止重放攻击：SSL使用序列号来保护通信方免受报文重放攻击
11、HTTPS的优缺点
优点：
1.使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户端和服务器
2.采用对称加密和非对称加密方式对数据进行加密，防止数据在传输过程中窃取，修改
缺点：
1.https协议握手阶段比较费时，会是页面的加载时间延长
2.https链接缓存不如http高效，会增加数据开销
3.https协议的安全是有范围的
4.SSL证书通常需要绑定IP，不能在同一个IP上绑定多个域名
12、HTTP1.1与HTTP1.0区别
1.HTTP1.0使用短链接，每次链接都需要建立新的TCP连接，连接不能复用，HTTP1.1开启‘connection：keep-alive’采用长连接，连接可以复用
2.host字段：在HTTP1.0中为每一台服务器绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名，HTTP1.1的请求和响应都支持host头域。
3.HTTP1.0中主要使用header里的If-Modified-Since，Expires来做为缓存判断的标准，而HTTP1.1采用Etag,If-None-Match等可供选择的缓存头来控制缓存策略
4.HTTP1.0存在一些浪费带宽的现象（比如：客户端只需要某个对象的一部分，而服务器却将整个对象发送过来，下载大文件不支持断点续传功能）
HTTP1.1则在请求头引入range头域，它允许只请求资源的某个部分
5.新增了一些错误状态码
13、HTTP1.1如何解决HTTP的对头阻塞问题？
对头阻塞：HTTP传输是基于请求-应答的模式进行的，报文必须是一发一收，里面的报文被放在一个任务队列中，一旦队首的请求处理太慢，就会阻塞后面请求的处理。
解决：
1.并发连接：一个域名允许分配多个长连接，那么就相当于增加了任务队列，不至于一个队伍的任务阻塞其他所有任务。（现在的标准浏览器，像谷歌是6个）
2.域名分片：将域名分成好几片，每片都可以连接多个长连接，所以能更好的解决队头阻塞的问题
14、HTTP2.0针对HTTP1.1做了那些优化
1.头部压缩
1）首先是在服务器和客户端之间建立哈希表，将用到的字段存放在这张表中，那么在传输的时候对于之间出现过的值，只需要把索引传给对方即可，对方拿到索引查表就行了，这种传索引的方式，可以说让请求字段得到极大程度的精简和复用
2）其次是对于整数和字符串进行哈夫曼编码，哈夫曼编码的原理就是先将所有出现的字符建立一张索引表，然后让出现次数多的字符对应得索引尽可能短，传输得时候也是传输这样得索引序列，可以达到非常高得压缩率
2.多路复用
用来解决队头阻塞得问题
二进制分帧：HTTP2.0将报文全部换成二进制格式，全部传输01串，方便机器得解析。原来Header+Body的报文格式如今被拆分了一个个二进制的帧，用Header帧存放头部字段，Data帧存放请求体数据，分帧之后，服务器看到的不再是一个个完整的 HTTP 请求报文，而是一堆乱序的二进制帧。这些二进制帧不存在先后关系，因此也就不会排队等待，也就没有了 HTTP 的队头阻塞问题。通信双方都可以给对方发送二进制帧，这种二进制帧的双向传输的序列，也叫做 流 (Stream)。HTTP/2用 流 来在一个 TCP 连接上来进行多个数据帧的通信
15、Cookie总结
1.本质：浏览器里面存储的一个很小的文本文件，内部以键值对的方式来存储，向同一域名下发送请求，都会携带相同的cookie，服务器拿到cookie进行解析，便能拿到客户端的状态，且服务器可以通过响应头中的Set-cookie字段来对客户端写入cookie。
2.属性
1）生命周期：cookie的有效时期可以通过Expries（过期时间）和Max-Age，【cookie过期会被删除】
2）作用域：有两个属性Domain和Path，给Cookie绑定域名和路径，在发送请求之前，发现域名或者路径和这两个属性不匹配，那么就不会带上cookie
3）安全相关：Secure--说明只能通过HTTPS传输cookie，如果Cookie字段带上HttpOnly---说明只能通过HTTP协议传输，不能通过js访问，也是预防xss攻击的重要手段。CSRF预防---SameSite
3.缺点
1）容量小，体积上面只有4kb
2)性能缺陷：cookie紧跟域名，不管域名下面的某个地址需不需要这个Cookie，请求都会携带上完整的Cookie，随着请求数的增多，其实会造成巨大的性能浪费。
3）安全缺点：cookie以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，进行篡改。在HttpOnly为false情况下，cookie信息能直接通过js脚本来读取。
16、HTTP代理
1.定义：代理的服务器相当于一个中间人角色，对于客户端而言，表现为服务器进行响应，对于源服务器，表现为客户端发起请求，具有双重身份。
2.功能
1）负载均衡：客户端的请求先到达代理服务器后，代理服务器拿到这个请求，通过特定的算法分发给不同的源服务器，让每个源服务器的负载尽量平均。
2）保障安全：利用心跳机制监控后台的服务器，一旦发生故障就将其剔除集群，并对上下文的数据进行过滤，对非法IP限流。
3）缓存代理：将内存缓存到代理服务器，使得客户端可以直接从代理服务器中获得，得而不用到源服务器哪里。
17、为什么要产生代理缓存？
对于源服务器来说，它也是有缓存的，比如Redis, Memcache，但对于 HTTP 缓存来说，如果每次客户端缓存失效都要到源服务器获取，那给源服务器的压力是很大的。
由此引入了缓存代理的机制。让代理服务器接管一部分的服务端HTTP缓存，客户端缓存过期后就近到代理缓存中获取，代理缓存过期了才请求源服务器，这样流量巨大的时候能明显降低源服务器的压力。【较少服务器的压力】
18、源服务器的缓存控制
1.private和public
在源服务器的响应头中，会加上 Cache-Control 这个字段进行缓存控制字段，那么它的值当中可以加入private或者public表示是否允许代理服务器缓存，前者禁止，后者允许。
2.proxy-revalidate
proxy-revalidate 则表示代理服务器的缓存过期后到源服务器获取
3.s-maxage
s是share 的意思，限定了缓存在代理服务器中可以存放多久，和限制客户端缓存时间的 max-age并不冲突
TCP协议
1、TCP与UDP区别
TCP是一个面向连接的、可靠的、基于字节流的传输层协议，UDP是一个面向无连接的基于数据报的传输层协议。
１）面向连接：在双方通信之前，TCP需要三个握手建立连接
２）可靠性：TCP会精准的记录那些数据发送了，那些数据被对方接受了，那些没有被接受，而且保证数据包按序到达，不允许半点差错，且当意识到丢包了或者网络环境不佳，TCP会根据具体情况调整自己的行为，控制自己的发送速度或者重发。
2、三次握手
目的：是为了确认双方的发送和接受的能力
第一次握手：客户端向服务器发送SYN包，等待服务器响应，并进入SYN-SEND状态
第二次握手：服务端收到SYN包，并确定SYN=ACK+1，然后响应一个SYN包和ACK包。并进入SYN-RECV状态
第三次握手：客户端收到服务端SYN+ACK包，向服务器发送确认包ACK。并进入ESTABLISHED状态
3、为什么不是两次、四次？
两次：无法确认客户端的接受能力
四次：可以，但没必要
4、三次握手可以携带数据吗？
第三次握手的时候，可以携带。前两次握手不能携带数据。
如果前两次握手能够携带数据，那么一旦有人想攻击服务器，那么他只需要在第一次握手中的SYN报文中放大量数据，那么服务器势必会消耗更多的时间和内存空间去处理这些数据，增大了服务器被攻击的风险。
第三次握手的时候，客户端已经处于ESTABLISHED 状态，并且已经能够确认服务器的接收、发送能力正常，这个时候相对安全了，可以携带数据。
5、四次挥手
刚开始双方都处于ESTABLISHED状态.
1.客户端要断开了，像服务端发送FIN报文，客户端变成FIN-WAIT1-状态。
2.服务端接受后向客户端发送ACK报文，变成CLOSEED-WAIT状态，客户端接受到了服务器的确认，变成FIN-WAIT2状态
3.服务端向客户端发送FIN+ACK报文，进入LAST-ACK状态
4.客户端收到服务器发来的FIN后，自己变成了TIME-WAIT状态，然后发送ACK给服务端。
此时，客户端需要等待2个MSL（报文最大生存时间），在这段时间内如果客户端没有收到服务端的重发请求，那么表示ACK成功到达，挥手结束，否则客户端重发ACK。
6、等待2MSL的意义（为什么）
不等待会怎样？
客户端发送的ACK报文段可能会丢失，若客户端不等待2MSL时间，则无法收到服务器重传的FIN+ACK报文段，所以不会重传ACK报文，则服务端将无法进入CLOSED状态。
1.保证客户端发送的最后一个ACK报文段能够到达服务器。这个ACK报文段有可能会丢失，使得处于WAIT-ACK状态的服务端接收不到对已发送的FIN+ACK的确认，服务端超时重传FIN+ACK报文，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文，从而重新发送ACK报文，重新启动2MSL计时器，最后客户端和服务端都进入CLOSED状态。
2、防止‘已失效的链接报文段’出现在本链接中。若客户端直接跑路，当服务端还有很多数据包要给客户端发，且还在路上的时候，此时客户端的端口此时刚好被新的应用占用，那么就接收到了无用数据包，造成数据包混乱。所以，最保险的做法是等服务器发来的数据包都死翘翘再启动新的应用。
7、为什么是四次挥手而不是三次？
关闭连接时，当服务器收到客户端发送的FIN报文时，很可能并不会立即关闭SOCKET，所以先回复一个ACK报文。只有等到服务器所有的报文都发送完了，才能发送FIN报文，因此不能一起发送。故需要四次挥手。
如果为三次握手，则客户端发送FIN报文后，长时间的延迟可能会导致客户端误以为服务端没有收到FIN报文，从而不断重新发送FIN。
8、半连接队列和SYN FLood攻击的关系
三次握手前，服务端的状态从CLOSED变成LISTEN，同时在内部创建两个队列：半连接和全连接
1、半连接队列：当客户端发送SYN到服务端，服务端收到后回复ACK和SYN，状态由LISTEN变成SYN_RCVD，此时这个链接就被推入半链接队列。
2、全连接队列：当客户端返回ACK，服务端接受后，三次握手完成。这个时候连接被推入另一个TCP维护的队列，也就是全连接队列。
3、SYNFlood攻击原理
SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单，就是用客户端在短时间内伪造大量不存在的 IP 地址，并向服务端疯狂发送 SYN 。对于服务端而言，会产生两个危险的后果：
1）处理大量的 SYN 包并返回对应 ACK , 势必有大量连接处于 SYN_RCVD 状态，从而占满整个半连接队列，无法处理正常的请求。
2）由于是不存在的 IP，服务端长时间收不到客户端的 ACK ，会导致服务端不断重发数据，直到耗尽服务端的资源。
9、TCP的流量控制？
对于发送端和接收端而言，TCP需要把发送的数据放到发送缓存区，将接收到的数据放到接受缓存区，流量控制要做的事情就是通过接受缓存区的大小，控制发送端的发送，如果对方的接受缓存区满了，就不要再继续发送了。
滑动窗口：发送窗口+接受窗口
10、TCP的拥塞控制
1.拥塞窗口：限制发送窗口的大小
2.慢启动：刚开始进入传输数据的时候，不要一次传输太多数据（因为网络不稳定时，容易丢包），首先，三次握手，双方宣告自己的接受窗口大小，双方初始化自己的拥塞窗口大小后，在开始传输的一段时间，发送端每收到一个ACK，拥塞窗口大小加1，依次类推，当到达慢启动阈值时，采用拥塞避免--到达阈值后，拥塞窗口只能加一点（1/拥塞窗口）
3.快速重传：当发送端收到3个重复的ACK时，意识到丢包了，于是马上进行重传，不需要等待一个RTO的时间；既然重传，并不是全部重传，而是选择性重传，接收端通过left edge和right edge告知发送端已经收到了那些区域的数据包，因此，进行一个选择性的重传。
4.快速恢复：当发送端接收到三次重复的ACK，意识到丢包，觉得网络有些拥塞了，自己会进入快速回复阶段。【将当前拥塞阈值前程拥塞窗口的一个，拥塞窗口线性增加】
