HTTP状态码
主要分为5类：
1XX：表示临时响应，并需要请求者继续执行操作的状态码
- 100：请求者应当继续提出请求。服务器返回此代码表示已收到请求的一部分，正在等待其余部分。
- 101：请求者已要求服务器切换协议，服务器已确认并准备切换。
2XX：表示成功处理了请求的状态码
- 200：服务器已经成功处理了请求，通常表示服务器已经提供了请求的网页。
- 201：请求成功并且服务器创建了新的资源
- 202：服务器已经接受请求，但尚未处理。
3XX：表示完成请求，需要进一步操作，用于重定向
- 301：永久性重定向，服务器返回此响应时，会自动将请求者转移到新位置。
- 302：临时重定向，请求者应该继续使用原有位置来进行以后的请求。
4XX：表示请求方有错误
- 400：请求方的请求有语法错误
- 403：服务器禁止访问，权限有关
- 404：服务器无法根据请求方的请求找到资源
5XX：表示服务端有错误
- 500：服务器遇到错误，无法完成请求
- 503：服务器目前无法使用，可能维护或者超载
301与302的区别
一个是永久性的, 如你访问www.baidu.com 会永久重定向为https://www.baidu.com, 以后的请求也会是从新的地址那去请求
而另一个是临时重定向, 如你未登录访问一个网站的个人中心, 这时可能会临时重定向到登录页面去, 客户端应当继续向原有地址发送以后的请求
HTTP常用的请求方式
GET：请求指定的页面信息，并返回实体主体
HEAD：类似于GET请求，只不过返回的响应中没有具体内容，用于获取报头
POST：向指定资源提交数据进行处理，一般用于创建资源
PUT：向服务端提交数据，用于更新资源
DELETE：删除服务器上的某些资源
CONNECT：HTTP/1.协议中预留给能够将连接改为管道方式的代理服务器
OPTIONS：返回所有可用的方法
TRACE：追踪请求-响应的传输路径
ISO七层模型
物联网输会示用
应用层：网络服务与最终用户的一个借口，有HTTP、FTP协议
表示层：数据的表示、安全、压缩。确保系统的应用层所发送的消息可用被另一个系统的应用层读取
会话层：建立、管理、终止会话，对应主机进程
传输层：定义传输数据的协议端口号，进行流量控制和差错校验。有TCP和UDP
网络层：进行逻辑地址寻址，路由选择，协议有ICMP，IP
数据链路层：在物理层提供的比特流服务的基础上，建立相邻节点之间的数据链路
物理层：建立、维护、断开物理连接
TPC/IP 四层模型
应用层：对应ISO模型中的应用层、表示层、会话层
传输层：对用ISO的传输层，为应用层实体提供端到端的通信功能，保证数据包的顺序传送和数据的完整性
网络层：对用ISO的网络层，主要解决主机到主机之间的通信问题
数据链路层：对用ISO的数据链路和物理层
HTTP协议的无状态
当浏览器第一次发送请求给服务器时，服务器响应了；如果同一个浏览器发去第二次请求给服务器，它还是会响应，但是服务器不知道你就是刚才那个浏览器。服务器不会记住你是谁，所以是无状态协议
一般通过cookie session来让HTTP协议变成有状态
从浏览器地址栏输入URL到显示主页的过程
- url解析，解析出要请求的资源，和域名，生成对应的HTTP请求报文
- DNS解析，查找域名对应的IP地址：首先会在浏览器的缓存中查看有没有对应的IP地址，有则直接使用，没有会向本地的DNS服务器中的缓存中查询，没有则由本地的DNS服务器去向根域名服务器查询是属于哪个顶级域名服务器，再去该顶级域名服务器查询属于哪个权限域名服务，最后向该权限域名服务器去查询对应的IP地址。
- 与服务器通过三次握手建立TCP连接
- 向服务器发送HTTP请求
- 服务器处理请求，返回网页内容
- 浏览器解析并渲染页面
- TCP四次挥手，连接结束
在传输的过程中还会使用到IP协议，给TCP报文加上IP头，用于远程定位，主要依靠DNS或得到的IP地址，再通过ARP协议，得到MAC地址，给IP数据包加上MAC头，完成点到点直接的传输
HTTP/1.0，1.1，2.0的区别
HTTP1.0和HTTP1.1的区别
HTTP1.1支持长连接，HTTP1.0则默认是不开启的，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。
分块传输编码，即服务端每产生一块数据，就发送一块，用”流模式”取代”缓存模式”。
HTTP1.1和HTTP2.0的区别
1.1版本的头信息是文本的ASCII编码，数据可以是ASCII编码，也可以是二进制编码。而2.0的头信息和数据体都是二进制编码，可以对头部进行压缩。
可以同一连接并发处理多个请求，不用按照顺序来进行请求，比如先请求了一个js文件之后，得到响应了再请求css，而2.0可以直接同时请求js和css
服务器可以主动向客户端推送资源，即使客户端没有发送请求。比如在请求HTML文件之后，服务器可以同时将html发送给你的同时，将css文件推送过来。
HTTP设置长连接
- http1的解析是基于文本协议的各式解析,而http2.0的协议解析是二进制格式,更加的强大
- 多路复用(Mutiplexing) : 一个连接上可以有多个request,且可以随机的混在一起,每个不同的request都有对应的id,服务端可以通过request_id来辨别,大大加快了传输速率
- header压缩: http1.x中的header需要携带大量信息.而且每次都要重复发送.http2.0使用encode来减少传输的header大小.而且客户端和服务端可以各自缓存(cache)一份header filed表,避免了header的重复传输,还可以减少传输的大小.
- 服务端推送(server push): 可以通过解析html中的依赖,只能的返回所需的其他文件(css或者js等),而不用再发起一次请求.
HTTP与HTTPS的区别
主要是从安全方面考虑，HTTPS是基于SSL/TLS安全套接层的HTTP协议，默认端口采用443，需要数字证书等技术，报文是密文方式传输
数字签名与数字证书
保密传输：
bob有一对公私钥，把公钥送给其他人，别人想要写信给bob可以用公钥进行加密，bob收到后用私钥进行解密，就可以看到该信息。
数字签名：
bob想要回信给别人，把自己的标识号和要写的内容，通过hash得到摘要，拿私钥对该摘要进行加密，付在摘要下面，别人拿到后，将加密内容用公钥解密，与上面的摘要进行对比，如果一致，说明是bob发送的。
但是数字签名无法证明公钥是否属于bob
数字证书：
找证书中心进行认证，CA将bob的信息和公钥用自己的私钥加密，形成数字证书，给bob，bob再与别人通讯时，不仅写上自己的签名，还附上CA颁发的证书，别人收到bob的消息时，就用CA的公钥进行解密，得到bob的公钥，再用bob的公钥验证数字签名，证明是bob发的消息。
HTTPS的流程
客户端向服务端发送加密请求
服务端用自己的私钥加密网页后，加自己的证书一起发给客户端
客户端完成对证书的验证后，产生对称秘钥，用服务器的公钥对自己的秘钥加密发给服务器
服务器用自己的私钥解密后，得到客户端的秘钥，再用客户端的秘钥进行加密返回内容，客户端就可以用自己的秘钥进行接下来的三次握手，而过程就一样，但是报文都是通过客户端生成的秘钥进行加密的。
TCP可靠传输
发送了seq=1，报文内数据包含3个字节，服务器会发送ACK=4的报文，请求接下来的数据。
连续发送了几个数据包，但是中间有数据包丢了，尽管服务器收到了后面的数据包，也会发送关于中间包的ACK
如果发送端一直没有接收到关于收到了某个包的ACK，会进行超时重传。
或者连续三次收到该数据包的冗余ACK，回进行快速重传
TCP状态图
Cookie, Session, Token
Cookie
工作机制如下
以加入购物车为例，每次浏览器请求后 server 都会将本次商品 id 存储在 Cookie 中返回给客户端，客户端会将 Cookie 保存在本地，下一次再将上次保存在本地的 Cookie 传给 server 就行了，这样每个 Cookie 都保存着用户的商品 id，购买记录也就不会丢失了
随着购物车内的商品越来越多，每次请求的 cookie 也越来越大，这对每个请求来说是一个很大的负担，我只是想将一个商品加入购买车，为何要将历史的商品记录也一起返回给 server ？购物车信息其实已经记录在 server 了，浏览器这样的操作岂不是多此一举？怎么改进呢
Session
仔细考虑下，由于用户的购物车信息都会保存在 Server 中，所以在 Cookie 里只要保存能识别用户身份的信息，知道是谁发起了加入购物车操作即可，这样每次请求后只要在 Cookie 里带上用户的身份信息，请求体里也只要带上本次加入购物车的商品 id，大大减少了 cookie 的体积大小，我们把这种能识别哪个请求由哪个用户发起的机制称为 Session（会话机制），生成的能识别用户身份信息的字符串称为 sessionId，它的工作机制如下
Token
看起来通过 cookie + session 的方式是解决了问题， 但是我们忽略了一个问题，上述情况能正常工作是因为我们假设 server 是单机工作的，但实际在生产上，为了保障高可用，一般服务器至少需要两台机器，通过负载均衡的方式来决定到底请求该打到哪台机器上。
Session复制
同一样的一份 session 保存了多份，数据冗余
Session粘连
这种方式是让每个客户端请求只打到固定的一台机器上，比如浏览器登录请求打到 A 机器后，后续所有的添加购物车请求也都打到 A 机器上，Nginx 的 sticky 模块可以支持这种方式，支持按 ip 或 cookie 粘连等等，如按 ip 粘连方式如下
这样的话每个 client 请求到达 Nginx 后，只要它的 ip 不变，根据 ip hash 算出来的值会打到固定的机器上，也就不存在 session 找不到的问题了，当然不难看出这种方式缺点也是很明显，对应的机器挂了怎么办？
Session共享
这种方式也是目前各大公司普遍采用的方案，将 session 保存在 redis，memcached 等中间件中，请求到来时，各个机器去这些中间件取一下 session 即可。
缺点其实也不难发现，就是每个请求都要去 redis 取一下 session，多了一次内部连接，消耗了一点性能，另外为了保证 redis 的高可用，必须做集群，当然了对于大公司来说, redis 集群基本都会部署，所以这方案可以说是大公司的首选了。
Token
实现单点登录比较便捷
TCP三次握手
正常情况：
不进行最后一次握手会怎样
- 服务器会不确定客户端是否能够收到自己的信息
- 如果在客户端一次握手超时后，又重新发了一次SYN，服务器接受到了后进行了连接的建立，数据传输，然后释放链接，此时第一次握手超时的报文到了，会误以为这是服务器又请求建立一次链接。并且没有第三次握手，服务端会发送完第二次握手的包之后直接进入ESTABLISHED状态，等到客户端发送数据，浪费服务端资源，如果有第三次握手，服务端发完第二次握手的包之后会等ACK，客户端发现服务请求SYN不合法，直接扔掉这个包，不会ACK，这样服务端等待的时间会少一些。
不正常情况：
也只会建立一个连接
TCP四次挥手
正常情况：
为什么挥手是四次
接受到客户端的断开连接的请求后，可能还会有数据没有发送完成，所以会先回应我接受到了要断开连接，然后把剩下的数据发完，之后再发送FIN为1的包
为什么要TIME_WAIT 2MSL
- 为了确保对方收到了ACK，在TIME_WAIT的时候，如果接收端一直没有收到ACK包，会重新发FIN包，如果此时发送方发完ACK包就直接关闭了连接，就收不到这个重发的FIN包了，那么接收端就一直无法正常关闭连接。
- 同时也可以保证这个连接和后面的连接不会混在一起。如果有一些失效的包在下一次同样的socket的建立后才到达，连接会以为是这次的数据包，会混淆。等待2MSL可以然后这些失效的包被丢弃。
不正常情况
TCP流量控制
自己来不及处理接收缓存区中的数据, 通过报文段中的窗口字段, 控制发送方不要发送太快, 导致数据丢失, 让网络产生不必要的负担
TCP拥塞控制
拥塞控制是站在全局角度看的, 限制过多的数据注入网络中, 因为发送窗口是取接收窗口和拥塞窗口的最小值, 这里控制全局的拥塞窗口, 就可以控制全局的发送端注入数据的速度
慢开始 拥塞避免
ssthresh门限值
快重传 快恢复
ICMP协议
差错报文
终点不可达
IP路由器无法将IP数据报发送给目的地址，会给发送端主机返回一个目标不可达的ICMP消息
源点抑制
另一端主机网络拥塞时，路由器会向发送端发送一个ICMP源抑制消息
时间超过
IP数据报中的TTL为0时，丢弃该数据报，并向源主机发送一个时间超时消息
参数问题
路由器接受到的数据报首部中有的字段的值不正确，则返回参数问题消息
改变路由（重定向）
路由器发现主机有更好的路由选择的时候，会向源主机发送改变路由的消息
询问报文
回送请求和回答报文
用于判断主机或者是路由器向特定的目的主机发出的询问，收到此报文，必须给源主机或路由器发送ICMP回送回答报文
时间戳请求和回答报文
请某个主机或者路由器回答当前的日期和时间，用于时钟同步和测量时间
PING程序
测试两个主机直接的连通性，使用了ICMP回送请求
Traceroute程序
跟踪一个分组从源点到终点的路径，使用了ICMP时间超过差错报文
Traceroute 使用 ICMP 报文和 IP 首部中的 TTL 字段，它充分利用了 ICMP 超时消息。其原理很简单，开始时发送一个 TTL 字段为 1 的 UDP 数据报，而后每次收到 ICMP 超时萧后，按顺序再发送一个 TTL 字段加 1 的 UDP 数据报，以确定路径中的每个路由器，而每个路由器在丢弃 UDP 数据报时都会返回一个 ICMP 超时报文，而最终到达目的主机后，由于 ICM P选择了一个不可能的值作为 UDP 端口（大于30000）。这样目的主机就会发送一个端口不可达的 ICMP 差错报文。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
