Java复习---网络

Posted 2021-07-18 赵jc

网络复习

• OSI 的七层模型都有哪些？
• 简述 tcp 和 udp的区别？
• 用UDP实现可靠传输(经典面试题)
• 三次握手
• 四次挥手
• 说一下 tcp 粘包是怎么产生的？
• Http状态码
• 在浏览器输入一个URL会发生什么呢？
• Session和Cookie
• Cookie
• Session
• Session和Cookie的区别
• get 和 post 请求有哪些区别？

OSI 的七层模型都有哪些？

• 应用层：直接为用户的应用进程（例如电子邮件、文件传输和远程登录）提供服务。直接和用户打交道。
• 表示层：数据的表示、安全、压缩。（可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取）
• 会话层：建立、管理、终止会话。
• 传输层：定义数据传输的端口号。
• 网络层：IP寻址，路由转发
• 数据链路层：建立逻辑连接、进行硬件地址寻址、差错校验等功能。
• 物理层：建立、维护、断开物理连接。

简述 tcp 和 udp的区别？

• TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。
• TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。
• TCP 是面向字节流的，UDP 是基于数据报的
• TCP用于可靠传输的情况, 应用于文件传输, ;而UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等.
  另外UDP 可以用于广播;
• 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。
• TCP既有发送缓冲区，又有接受缓冲区，而UDP只有接受缓冲区

用UDP实现可靠传输(经典面试题)

例如:

• 引入序列号, 保证数据顺序;
• 引入确认应答, 确保对端收到了数据;
• 引入超时重传, 如果隔一段时间没有应答, 就重发数据;

三次握手

三次握手的目的就是为了验证发送端和客户端的发送能力和接受能力。
Tcp两次握手不可以，不能完全验证发送端和接收端的的接受和发送能力。Tcp四次也可以，但没必要。

四次挥手

服务器端和客户端都需要关闭，但客户端缓冲区可能会有未完成的任务，所以需要四次握手才可以。
Tcp三次挥手可能性（如果服务器没有要处理的任务可以，否则不可以）

TIME_WAIT

想一想, 为什么是TIME_WAIT的时间是2MSL?

• MSL是TCP报文的最大生存时间,因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启,可能会收到来自上一个进程的迟到的数据,但是这种数据很可能是错误的);
• 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN.这时虽然客户端的进程不在了,但是TCP连接还在, 仍然可以重发LAST_ACK);

CLOSE_WAIT

• 一般而言，对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题.

说一下 tcp 粘包是怎么产生的？

首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.而且只有TCP会产生粘包问题，而UDP不会产生（使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况.所以UDP不会出现粘包问题）

采用TCP协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据；这样会产生粘包问题。

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

• 每次都按固定大小发送和读取即可（不现实）
• 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

Http状态码

• 200：请求成功，一般用于get和post请求
• 301（重定向）：永久重定向，请求的资源已经被永久移动到新的URL，之后任何新的请求都会用新的URL代替
• 302（转发）：临时重定向，与301类似，只是资源被临时移动，客户端应继续使用原有的URL

转发和重定向的区别：

• 重定向（Redirect）：返回3XX状态码+Location响应头，表示要跳转的路径，浏览器接收到相应数据后自动跳转，两次请求
• 转发（Forward）：一次请求，后端接收直接把转发路径的资源作为响应体返回

区别：

• URL路径是否改变：重定向会改变，转发不会

• 发起的网络请求次数：重定向发起两次，转发发起一次

• 400：客户端请求的语法错误（http协议格式不对、请求数据格式、数据类型等书写错误）

• 401：未经许可，需要通过HTTP认证；（需要登录的网页）

• 403：服务器理解客户端的请求，但拒绝了（权限不够）

• 404：服务器无法根据客户单的请求找到资源（找到了相应的主机，但没找到资源）

• 405：客户端请求中的方法被禁止（没有重写）

• 500:服务器内部错误（后端代码有错误）

在浏览器输入一个URL会发生什么呢？

在浏览器输入一个URL会发生什么呢？

1. 浏览器（客户端）会判断当前输入的URL是否合规，然后进行地址解析，补全域名，最后DNS域名解析获得目的IP；
2. 根据目的IP计算是否和主机在同一个网段，如果在则直接转发，如果不在同一个网段，则使用ARP协议，查找本地局域网网关的MAC地址，则发送数据报到网关
3. 在路由器（网关处）进行NAT/NAPT技术，将私网IP变为公网IP，再根据路由器进行路由转发（封装和分用），找到目的主机
4. 路由器转发的过程中每次进行TCP三次握手
5. 连接建立后，客户端以HTTP协议的数据格式发送数据给客户端
6. 服务器业务代码处理请求数据并把结果返回给浏览器
7. 在进行路由选择，返回给主机所在的外网，再使用NAT/NATP的反向映射给局域网中的主机IP
8. 浏览器（主机）拿到服务器返回的信息进行渲染
9. 四次挥手正常断开链接

Session和Cookie

Http 是一个无状态协议, 就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速（但服务器连接是数量限制的，为65535）。坏处是需要进行用户状态保持的场景时[比如，登陆状态下进行页面跳转，或者用户信息多页面共享等场景]，否则无法实现，而如何保持呢，就需要使用一些方式或者手段比如： session 和cookie

Cookie

• cookie是保存在客户端本地的文件
• cookie常用于免登陆
• 登陆成功后响应头返回Set-Cookie,之后每次都会自动携带Cookie头

用户第一次登陆通过之后，服务端响应头携带Set-Cookie信息，告诉客户端，让浏览器自动设置Cookie到本地，之后的每次请求浏览器都会自动携带Cookie头（将用户的信息保存在客户端本地（和浏览器相关的本地路径下），域名绑定用户信息的cookie，之后在此访问某个域名的时候，浏览器自动从本地抓取该域名的cookie信息）如下图：

Session

使用场景
Cookie解决了一定的问题，但是又引进了新的安全问题，一旦cookie丢失，用户信息泄露，而且可以随意修改cookie的值来模拟登陆，所以有了另一种解决方法，将用户敏感信息保存至服务器

实现
1、 登陆成功后，服务器生成随机的字符串sessionid（类似于通行证），保存在tomcat的用户信息数据结构中，一个sessionid绑定一个用户，但一个用户保存多个信息
2、 然后将sessionid放在响应头的一个键值对里（键是双方约定好的，值就是sessionid的值）
3、客户端之后的请求，都会携带sessionid（例如JSESSIONID=xxxxx）
4、服务端接收请求，验证sessionid（在map中根据通行证号，查询用户，来判断是否登录）

小结：

• session用于会话，保持身份验证（主要解决敏感资源的访问问题）
• session的信息保存在服务器当中
• session在会话结束（超时/注销），或者服务器重启后会消失

Session和Cookie的区别

• Cookie以文本文件格式存储在浏览器中，而session存储在服务端
• 因为每次发起Http 请求，都要携带有效Cookie信息，所以Cookie一般都有大小限制，以防止增加网络压力,一般不超过4k
• 可以轻松访问cookie值但是我们无法轻松拿到会话值，因此session方案更安全

get 和 post 请求有哪些区别？

GET的请求数据只能放在URL中(万恶的源泉），所有就导致了一系列的问题。

• 1.首先GET方法的数据类型只能为ASCII码格式（POST为任意格式）
• 2.GET发送的数据有长度限制（POST没有限制）
• 3.GET请求数据放在URL中，这样会直接显示出来，所以不安全，且一般请求正文 为空（POST可以将数据放在请求正文中，所以相对来说比较安全）