Java复习---网络

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. 四次挥手正常断开链接

DNS域名解析

域名的分类

www.cskaoyan.com

• www是三级域名
• cskaoyan是二级域名
• com是一级域名

首先需要了解几个域名服务器

（1）根域名服务器

• 根域名服务器是最高层次的域名服务器，所有的根域名服务器都知道所有的顶级域名服务器的IP地址。
• 根域名服务器也是最重要的域名服务器，不管是哪个本地域名服务器，若要对因特网上任何一个域名进行解析，只要自己无法解析，就首先要求助于根域名服务器。
• 因特网上有13个根域名服务器，尽管我们将这13个根域名服务器中的每个都视为单个服务器，但每个“服务器”实际上是冗余服务器的集群，以提供安全性和可靠性。
• 需要注意的是，根域名服务器用来管辖顶级域(如.com)，通常它并不直接把待查询的域名直接转换成IP地址，而是告诉本地域名服务器下一步应当找哪个顶级域名服务器进行查询。

（2）顶级域名服务器

• 这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。
• 收到DNS查询请求时,就给出相应的回答(可能是最后的结果，也可能是下一步应当查找的域名服务器的IP地址)。

（3）授权域名服务器(权限域名服务器)

• 每台主机都必须在授权域名服务器处登记。为了更加可靠地工作，一台主机最好至少有两个授权域名服务器。
• 实际上，许多域名服务器都同时充当本地域名服务器和授权域名服务器。 授权域名服务器总能将其管辖的主机名转换为该主机的IP地址。

（4）本地域名服务器

• 本地域名服务器对域名系统非常重要。
• 每个因特网服务提供者(ISP)， 或一所大学，甚至一所大学中的各个系，都可以拥有一个本地域名服务器。
• 当一台主机发出DNS查询请求时，这个查询请求报文就发送给该主机的本地域名服务器。
• 事实上，我们在Windows系统中配置“本地连接”时，就需要填写DNS地址，这个地址就是本地DNS (域名服务器)的地址。

查询方式主要有两种：递归查询和迭代查询

递归查询（比较少用）

递归与迭代结合查询


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可以将数据放在请求正文中，所以相对来说比较安全）

https

因为http是明文传输的，不安全的，所以我们使用https加密的方式来传输数据。(https是基于http+ssl实现的，比http安全，但传输效率比http低)

首先需要知道几个具体的感念，对称加密和非对称加密，客户端，服务端（网站），CA机构

• 对称加密：浏览器和网站要使用相同的密钥才能正常对数据进行加解密，但是如何让这个密钥只让它们俩知晓，而不被任何监听者知晓呢？你会发现不管怎么商定，浏览器和网站的首次通信过程必定是明文的。这就意味着，按照上述的工作流程，我们始终无法创建一个安全的对称加密密钥。
• 非对称加密：如果我们想要安全地创建一个对称加密的秘钥，可以让浏览器这边来随机生成，但是生成出来的密钥不能直接在网络上传输，而是要用网站提供的公钥对其进行非对称加密。由于公钥加密后的数据只能使用私钥来解密，因此这段数据在网络上传输是绝对安全的。而网站在收到消息之后，只需要使用私钥对其解密，就获取到浏览器生成的密钥了。（另外，使用这种方式，只有在浏览器和网站首次商定密钥的时候需要使用非对称加密，一旦网站收到了浏览器随机生成的密钥之后，双方就可以都使用对称加密来进行通信了，因此工作效率是非常高的）
• 客户端：我们自己的主机，发送网址请求
• 服务端：我们访问请求的网站
• CA机构，权威机构，为网站颁发CA证书的

具体的步骤

• 首先，我们的网站会向CA机构发送请求，（请求中包含自己网站的公钥、和自己网站的一些域名信息或ip地址），请求CA机构为自己授权证书

• CA机构验证我们的网站合法后，会为我们制作证书，CA机构会使用自己的私钥对其加密，并将加密后的数据返回给我们，我们只需要将获得的加密数据配置到网站服务器

• 然后，每当有浏览器请求我们的网站时，首先会将这段加密数据返回给浏览器，此时浏览器会用CA机构的公钥来对这段数据解密。

• 如果能解密成功，就可以得到CA机构给我们网站颁发的证书了，其中当然也包括了我们网站的公钥。再在浏览器随机生成字符串作为之后双方通信的秘钥，通过对应网站的公钥进行加密传输

• 网站拿到数据后用自己网站的私钥在进行解密（非对称加密），得到约定的秘钥，自后就可以用只有两个人知道的秘钥进行通信就可以啦（对称加密）