Java横向技术网络【笔记】

计算机网络

服务器返回给客户端 http 响应包的状态码有哪几大类？302、304 分别是什么意思？

状态码分为五大类：

（1）信息性状态码（Informational），表示请求已被接受，需要继续处理。码值范围：1xx

（2）成功状态码（Success），表示请求已成功被服务器接收、理解、并接受。码值范围：2xx

（3）重定向状态码（Redirection） ，表示需要客户端采取进一步的操作才能完成请求。码值范围：3xx

（4）客户端错误状态码（Client Error），表示请求语法错误或者请求无法完成。码值范围：4xx

（5）服务器端错误状态码（Server Error），表示服务器在处理请求的过程中发生了错误或者无法执行请求。码值范围：5xx

302表示暂时性重定向，可以简单的理解为该资源原本确实存在，但已经被临时改变了位置，换而言之，就是请求的资源暂时驻留在不同的URI下

304表示资源在由请求头中的 If-Modified-Since 或 If-None-Match 参数指定的这一版本之后，未曾被修改，表示客户端不用请求该资源，直接使用本地的资源即可

常见状态码

100，表示迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它

101，表示服务器正在切换协议，只能切换到更高级的协议

200，请求已成功，请求所希望的响应头或数据体将随此响应返回

202，服务器已接受请求，但尚未完成。最终该请求可能会也可能不会被执行，并且可能在处理发生时被禁止

301，永久性重定向，被请求的资源已永久移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址

400，通常有两种情况：一是语义有误，当前请求无法被服务器理解，二是请求参数有误

401，请求要求身份验证，该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息，客户端可以重复提交一个包含恰当的 Authorization 头信息的请求，如果当前请求已经包含了 Authorization 证书，那么 401 响应代表着服务器验证已经拒绝了那些证书，对于需要登录的网页，服务器可能返回此响应

403，服务器已经理解请求，但是拒绝执行它

404，服务器找不到请求的资源

405，禁用请求中指定的方法

500，服务器内部错误，不知道如何处理

502，前面的网关代理服务器联系不到后端的服务器

503，服务器没有准备好处理请求，常见原因是服务器因维护或重载而停机

504，前面的网关代理服务器能联系到后端的服务器，但是后端的服务器在规定的时间内没有给代理服务器响应

说一说在浏览器地址栏输入 URL 到页面展示，这中间发生了什么？

整体上可分这几步：

（1）用户输入 URL 并回车

（2）浏览器处理 URL

首先，浏览器进程检查 URL，组装协议，构成完整的 URL，然后，浏览器进程通过进程间通信把 URL 请求发送给网络进程，在网络进程获取到 URL后，先去本地缓存中查找是否有缓存文件，如果有，拦截请求，直接 200 返回，否则，进入网络请求过程

（3）建立网络连接

首先，网络进程请求 DNS 返回域名对应的 IP 和端口号，如果之前 DNS 数据缓存服务缓存过当前域名信息，就会直接返回缓存信息，否则，请求将使用域名解析得到的 IP 和端口号，如果没有端口号，http 默认 80，https 默认 443，如果是 https 请求，还需要建立 TLS 连接

然后TCP通过三次握手同服务端建立起链接，细分一下的话，即传输层会把 http 请求加上 TCP 头部，其包括源端口号、目标程序端口号和用于校验数据完整性的序号，然后向下传输到网络层，网络层在数据包上加上 IP 头部，其包括源 IP 地址和目标 IP 地址，继续向下传输到底层，而底层通过物理网络传输给目标服务器主机，目标服务器网络层接收到数据包后，解析出 IP 头部，识别出数据部分，将解开的数据包向上传输到传输层，最后目标服务器传输层获取到数据包，解析出 TCP 头部，识别端口，将解开的数据包向上传输到应用层

(4) 服务端处理数据流程

服务端由于规模不同，架构不同，通常处理流程有一些差异，不过大致可以分为：

第一步，网络接入层处理请求 URL，并路由给真正的应用服务器集群，网络接入层一般是 nginx和apache 服务器，进行请求转发、负载均衡等

第二步，应用服务器处理真正的业务逻辑，通常会通过 SOA、微服务等方式调用下游的业务服务，通常还包括缓存读写逻辑等

第三步，业务逻辑最终会和数据库结合起来，在进行一系列的数据增删查改后，通过 SOA、微服务等方式返回给调用方具有业务语义的数据

（5）浏览器解析渲染过程

首先，网络进程将获取到的数据包进行解析，根据响应头中的 Content-type 来判断响应数据的类型，如果是字节流类型，就将该请求交给下载管理器，流程结束，如果是 text/html 类型，就通知浏览器进程获取文档准备渲染

然后，浏览器进程获取到通知，根据当前页面 B 是否是从页面 A 打开的并且和页面 A 是否是同一个站点（根域名和协议一样就被认为是同一个站点），如果满足上述条件，就复用之前网页的进程，否则，新创建一个单独的渲染进程

渲染进程对文档进行页面解析和子资源加载后，HTML 通过 HTM 解析器转成 DOM Tree，CSS 按照 CSS 规则和 CSS 解释器转成 CSSOM TREE，两个 tree 结合，形成 render tree（不包含 HTML 的具体元素和元素要画的具体位置），通过 Layout 可以计算出每个元素具体的宽高颜色位置，结合起来，开始绘制，最后显示在屏幕中新页面显示出来

说下TCP三次握手的过程？

第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态,等待服务器确认，其中SYN是同步序列编号(Synchronize Sequence Numbers)

第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

完成三次握手,客户端与服务器开始传送数据

为什么要三次握手？

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的

第一次握手：Client 什么都不能确认，Server 确认了对方发送正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常，Server 确认了：自己接收正常，对方发送正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常，Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可

三次握手为什么要传回SYN?

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号

SYN 是 TCP/IP 建立连接时使用的握手信号，在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement，确认字符，在数据通信传输中，接收站发给发送站的一种传输控制字符，它表示确认发来的数据已经接受无误）消息响应

这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递

三次握手里，已经传了 SYN，为啥还要传 ACK?

双方通信无误必须是两者互相发送信息都无误

传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证

说下断开一个 TCP 连接的“四次挥手”

1.客户端-发送一个FIN，用来关闭客户端到服务器的数据传送

2.服务器-收到这个FIN，它发回一个ACK，确认序号为收到的序号加1，和SYN一样，一个FIN 将占用一个序号

3.服务器-关闭与客户端的连接，发送一个FIN给客户端

4.客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

为什么要四次挥手？

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态，当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接

生活中的例子，就像是朋友之间语音聊天，我说完了我想说的，和朋友说，我说完了，没啥说的了，但是我朋友还想说点啥，就说，等等，等我说完在溜，然后继续唠嗑，直到他说完，说，我也整完了，这才算聊完

TCP,UDP 协议的区别？

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认，虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信）

TCP 提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接，TCP 不提供广播或多播服务，由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等，这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源

TCP 协议如何保证可靠传输？

八点来保证可靠传输：

1.应用数据被分割成 TCP 认为最适合发送的数据块

2.TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层

3.校验和： TCP 将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化，如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段

4.TCP 的接收端会丢弃重复的数据

5.流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据，当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失，TCP 使用的流量控制协议是可变大小的滑动窗口协议

6.拥塞控制：当网络拥塞时，减少数据的发送

7.ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组

8.超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段，如果不能及时收到一个确认，将重发这个报文段

HTTP长连接和短连接？

在HTTP/1.0中默认使用短连接，也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接

当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源，每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话

而从HTTP/1.1起，默认使用长连接，用以保持连接特性，在使用长连接的情况下（在响应头中加入Connection:keep-alive），当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接

Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件中设定这个时间，实现长连接需要客户端和服务端都支持长连接

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接

HTTP 1.0和HTTP 1.1的主要区别是什么?

主要区别主要体现在：

1.长连接：在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接，HTTP 是基于TCP/IP协议的，每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大，因此最好能维持一个长连接，可以用个长连接来发多个请求

HTTP/1.1起，默认使用长连接，默认开启Connection：keep-alive，HTTP/1.1的持续连接有非流水线方式和流水线方式，流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文，与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求

2.错误状态响应码：在HTTP 1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突，410（Gone）表示服务器上的某个资源被永久性的删除

3.缓存处理：在HTTP 1.0中主要使用header里的If-Modified-Since，Expires来做为缓存判断的标准，HTTP 1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since等更多可供选择的缓存头来控制缓存策略

4.带宽优化及网络连接的使用：HTTP 1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP 1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接

URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是同一资源标志符，可以唯一标识一个资源

URL(Uniform Resource Location) 是同一资源定位符，可以提供该资源的路径，它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源

URI的作用像身份证号一样，URL的作用更像家庭住址一样，URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息

HTTP和HTTPS的区别？

1. https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用

2. https是具有安全性的ssl加密传输协议，而http是超文本传输协议，信息是明文传输

3. http和https使用的是完全不同的连接方式，用的端口也不一样，http是80，https是443

4. http的连接很简单，是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

Cookie和Session的区别是什么？

1. cookie数据存放在客户的浏览器上，session数据放在服务器上

2. cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session

3. session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE

4. 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie

总的来说，Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样

Cookie 一般用来保存用户信息，比如我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了，而且登录一次网站后访问网站其他页面不需要重新登录

Session 的主要作用就是通过服务端记录用户的状态，典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的，服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了