你好offer之--计算机网路

计算机网络

osi七层模型：物联网叔会试用

物理层

比特流传输

链路层

控制网络层与物理层的通信

网络层

ip寻址和路由选择

传输层

两台主机进程之间的通信提供服务。传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

会话层

负责建立（身份验证，权限鉴定）、管理和终止表示层实体之间的通信会话

表示层

使通信的应用程序能够解释交换数据的含义。该层提供的服务主要包括数据压缩，数据加密以及数据描述

应用层

通过应用程序间的交互来完成特定的网络应用。该层协议定义了应用进程之间的交互规则，通过不同的应用层协议为不同的网络应用提供服务。

五层协议

应用层、传输层、网络层、链路层和物理层

UDP相关

UDP连接前不进行三次握手，发送数据之前不需要建立连接，所以UDP具有较好的实时性，适用于及时通信。但是UDP只管发送数据，数据报发出去，就不保留数据备份，不能保证数据的可靠性

UDP支持一对一，一对多，多对一和多对多的交互通信而TCP连接只能是点到点的

TCP相关

TCP的三从握手和四次挥手

TCP通过三次握手建立一个连接，通过四次挥手来关闭一个连接

三次握手主要是为了确认通信双方收发数据的能力是正常的

三次握手

第一次握手：客户端向服务端发送连接请求，客户端随机生成一个起始序列号，客户端向服务端发送报文（包含syn和序列号）。此次证明服务端能够发送消息
第二次握手：服务端收到客户端发送来的报文后，发现syn，知道这是一个同步请求，然后将客户端的序列号保存下来。并随机生成一个服务端的序列号。向客户端发送确认报文（syn和相应ack（客户端的序列号+1）以及服务端的序列号以及ACK标志位）（此次证明服务端的收发能力都可以）
第三次握手：客户端收到回复后，发现syn为1，知道服务端同意了连接，然后保存服务端的序列号，再向服务端发送一段报文（syn和相应ack（服务端的序列号+1）以及客户端的序列号以及ACK标志位）。至此客户端和服务端建立起连接（此次证明客户端的收能力正常）

注意：不携带数据的ACK报文是不占据序列号的，所以后面第一次正式发送数据时seq还是原来的

四次挥手

第一次挥手：当客户端的数据传输完的时候，客户端向服务端发送报文（包含fin和seq），申请断开连接。
第二次挥手：服务器收到客户端发来的fin报文后，给客户端回复确认报文（包含一个序列号和一个ack（序列号+1）和ACK标志），此时客户端处于半关闭状态，因为服务器可能还有数据没发完
第三次挥手：服务端将数据发送完毕后向客户端发送连接释放报文（fin和ack以及seq和ACK标志位）
第四次挥手:客户端收到服务端的释放报文后向服务端发送确认报文（ack，seq，ACK）。发送完确认报文后要等待两个发送周期后才释放TCP连接，服务端收到客户端的确认报文后会立即释放TCP连接

为什么TCP连接的时候是3次

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。

如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

为什么TCP连接的时候是3次，关闭的时候却是4次

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了，服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

TCP粘包

发送方发送的若干包数据到接收方接收时粘成一包

为什么出现粘包现象

发送方原因：TCP默认会使用Nagle算法（数据在发送端被缓存，如果缓存到达指定大小就将其发送，或者在上一个数据的应答包到达，将缓存区一次性全部发送），正是Nagle算法造成了发送方有可能造成粘包现象。
接收方原因：TCP接收到分组时，并不会立刻送至应用层处理。TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

TCP粘包该怎么做

如果发送方发送的多个分组本来就是同一个数据的不同部分，当然不需要处理粘包的现象。但如果多个分组本毫不相干，我们就一定要处理粘包问题了
固定发送信息长度，或在两个信息之间加入分隔符。

滑动窗口协议

最大效率的利用网络资源，增加网络的吞吐量

采用发送确认机制来保证次序，采用多包同时发送来保证高吞吐

问题：我们每次需要发多少个包过去呢？发送多少包是最优解呢？
每收到一个新的确认(ack)，滑动窗口的位置就向右移动一格。
如果发送过程中包丢了，采取超时重发机制

DNS解析

浏览器通过域名（例如：www.baidu.com）发起一个网络请求的时候，会有DNS服务器将域名解析成ip地址，以便向正确的ip地址发送请求。

DNS：是一个域名系统，将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS在区域传输的时候使用TCP协议,其他时候使用UDP协议

DNS解析：互联网都是通过URL来请求资源的，而URL中的域名需要解析成IP地址才能与远程主机建立连接，将域名解析成IP地址就属于DNS解析的工作范畴。

域名结构

一个完整的域名由2个或2个以上的部分组成，各部分之间用英文的句号“.”来分隔
如域名mail.cctv.com，其中：com为顶级域名（ top-level-domain，TLD）， cctv为二级域名，mail为三级域名

DNS的解析过程：

用户在自己的浏览器中输入要访问的网站域名。
浏览器首先看看自己缓存和本地操作系统中有没有对应的ip地址，如果有记录则直接响应用户请求
如果没有，浏览器向会本地DNS服务器请求对该域名的解析。
本地DNS服务器中如果缓存有这个域名的解析结果，则直接响应用户的解析请求。
本地DNS服务器中如果没有缓存这个域名的解析结果，就会将此请求发送到根DNS服务器，本地DNS服务器和根DNS服务器会以递归的方式一级一级接近查询的目标，获取解析结果后将其返回给本地DNS服务器。
DNS服务器在返回给浏览器

CDN原理，CDN加速过程

CDN就是根据用户位置分配最近的资源

通过将网络内容发布到最靠近用户的『边缘节点』，使不同地区的用户在访问相同页面、图片或视频时就可以就近获取。

CDN本质是一种分布式缓存系统，无需考虑数据持久化，如果缓存服务器出现问题，在缓存集群中标记为删除即可。

CDN的优点：

根据用户与业务服务器的距离，自动选择就近的cache服务器
镜像服务，消除运营商之间互联的瓶颈影响，保证不同网络的用户都能得到良好的访问质量
分担网络流量，减轻压力

引入CDN后访问网站的流程

当用户输入网址回车后，经过本地DNS系统解析，DNS会将最终的域名解析权交给CNAME 指向的CDN 专用DNS服务器。
CDN的DNS服务器将 CDN的全局负载均衡目的ip 地址返回给浏览器
用户向 CDN的全局负载均衡服务器发起内容url 请求
CDN全局负载均衡服务器根据用户请求的IP地址，url等信息，选择一台离用户距离近，缓存服务器上有用户所需内容，以及负载均衡合适的边缘服务器，发给用户
用户向这个选中的边缘服务器发起请求。边缘服务器响应用户请求，将用户所需内容传送到用户终端。如果边缘服务器上没有用户想要的内容，那么这台服务器就会向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器，并将内容拉取到本地。

网页解析全过程

DNS 解析
当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。
TCP 连接
浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。
发送 HTTP 请求
浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。

GET和POST区别

Get是不安全的，因为在传输过程，数据被放在请求的URL中；Post的所有操作对用户来说都是不可见的。
Get请求提交的url中的数据最多只能是2048字节，Post请求则没有大小限制。
Get执行效率比Post快
GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去。而对于POST，浏览器先发送header，浏览器再发送data

Session、Cookie和Token的主要区别

HTTP协议本身是无状态的。什么是无状态呢，即服务器无法判断用户身份。

Cookie

cookie是由Web服务器保存在用户浏览器上的小文件，包含用户相关的信息。客户端向服务器发起请求，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户身份。

session

session是依赖Cookie实现的。session是服务器端对象,session 在浏览器和服务器会话过程中，服务器分配的一块储存空间。服务器默认为浏览器在cookie中设置 sessionid，浏览器在向服务器请求过程中传输 cookie 包含 sessionid ，服务器根据 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。

cookie与session区别

cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高；
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，session无此限制
session一定时间内保存在服务器上，当访问增多，占用服务器性能，考虑到服务器性能方面，应当使用cookie。

token

Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

session与token区别

session机制存在服务器压力增大，CSRF跨站伪造请求攻击，扩展性不强等问题；
session存储在服务器端，token存储在客户端
token提供认证和授权功能，作为身份认证，token安全性比session好；
session这种会话存储方式方式只适用于客户端代码和服务端代码运行在同一台服务器上，token适用于项目级的前后端分离（前后端代码运行在不同的服务器下）

servlet

servlet用来接收客户端的请求数据，然后调用底层service处理数据并生成结果

客户端发送请求到服务器端
服务器将请求信息发送至Servlet
Servlet生成响应内容并将其传给服务器。
服务器将响应返回给客户端。

servlet的作用域：

request(请求)：它的作用范围是一次请求和响应，是三个作用域中最小的。
session（会话）：它的作用比request要大一点，一次会话过程中，它的作用域就一直存在，(默认是30分钟)
servletcontext：它作用范围最大，作用于整个服务器中。服务器启动时创建，服务器关闭时销毁。（Application）

servlet生命周期：

Web容器加载Servlet并将其实例化后，Servlet生命周期开始，容器运行其init()方法进行Servlet的初始化；
调用Servlet的service()方法，service()方法会根据需要调用与请求对应的doGet或doPost等方法；
当服务器关闭或项目被卸载时服务器会将Servlet实例销毁，此时会调用Servlet的destroy()方法。

Servlet是线程安全的吗

Servlet不是线程安全的，多线程并发的读写会导致数据不同步的问题。

解决的办法是尽量不要在实现servlet接口的类中定义实例变量，而是要把变量分别定义在doGet()和doPost()方法内。虽然使用synchronized(name){}语句块可以解决问题，但是会造成线程的等待，不是很科学的办法。

跨域问题

使用@CrossOrigin注解

Socket

计算机之间进行通信的一种约定。网络上的两个程序通过一个双向的链路连接实现数据的交换，这个双向链路的一端称为一个Socket，一个Socket由一个IP地址和一个端口确定唯一性。

Socket编程主要是指基于TCP/IP协议的网络编程

socket连接就是所谓的长连接，客户端和服务器需要互相连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉的，但是有时候网络波动还是有可能的。

socket 的典型应用

Web 服务器和浏览器：
浏览器获取用户输入的 URL，向服务器发起请求，服务器分析接收到的 URL，将对应的网页内容返回给浏览器，浏览器再经过解析和渲染，就将文字、图片、视频等元素呈现给用户。

Socket通讯的过程

服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把响应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。
基于UDP：UDP 协议是用户数据报协议的简称，也用于网络数据的传输。虽然 UDP 协议是一种不太可靠的协议，但有时在需要较快地接收数据并且可以忍受较小错误的情况下，UDP 就会表现出更大的优势。我客户端只需要发送，服务端能不能接收的到我不管

HTTP

http协议是超文本传输协议。它是基于TCP协议的应用层传输协议，即客户端和服务端进行数据传输的一种规则。该协议本身HTTP 是一种无状态的协议。

http和https的区别

HTTPS=HTTP协议＋TLS/SSL
HTTP存在的不足主要是不安全，容易被第三方窃听篡改和冒充

HTTPS是添加了加密和认证机制的HTTP
由于加密处理，会消耗更多的CPU和内存资源
HTTPS引入了证书，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段

HTTPS的整体过程分为证书验证和数据传输阶段

证书验证阶段
浏览器发起 HTTPS 请求服务端返回 HTTPS 证书客户端验证证书是否合法，如果不合法则提示告警

数据传输阶段
当证书验证合法后，在本地生成随机数通过公钥加密随机数，并把加密后的随机数传输到服务端服务端通过私钥对随机数进行解密服务端通过客户端传入的随机数构造对称加密算法

HTTPS的优化：

通信内容进行加密，防止信息在传输过程中泄露
保证数据完整性、准确性
对数据来源进行验证，确保来源无法伪造

HTTPS是使用了证书和加密的一个混合密码系统，其中证书的作用在于传递会话密钥，以及验证网站的真实性

HTTPS工作原理：

服务器将公钥证书返回给客户端
客户端验证公钥证书
客户端生成会话密钥，然后用公钥进行加密，发给服务端
服务端用私钥进行解密得到会话密钥客户端和服务器就都存在
服务端使用会话密钥加密明文内容
客户端使用会话密钥进行解密得到明文内容
客户端也可以通过会话密钥加密明文内容发给服务端，服务端通过会话密钥解密得到明文内容

一次完整的HTTP请求所经历几个步骤?

根据域名和 DNS 解析到服务器的IP地址 (DNS + CDN)
获得IP地址对应的物理机器的MAC地址
浏览器对服务器发起 TCP 3 次握手
建立 TCP 连接后发起 HTTP 请求报文
服务器响应 HTTP 请求，将响应报文返回给浏览器
短连接情况下，请求结束则通过 TCP 四次挥手关闭连接，长连接在没有访问服务器的若干时间后，进行连接的关闭
浏览器得到响应信息中的 HTML 代码
浏览器对页面进行渲染并呈现给用户

常用HTTP状态码

1xx 服务器收到请求，需要请求者继续执行操作
2xx 成功
3xx 重定向，需要进一步的操作以完成请求
4xx 客户端错误
5xx 服务器错误

HTTP1.0和HTTP1.1和HTTP2.0的区别

HTTP1.0和HTTP1.1的区别：

HTTP1.1支持长连接
HTTP1.1中新增了24个错误状态响应码
HTTP1.1支持可以只发送header信息（header主要来存放cookie，token等信息的，
body主要用来存放post的一些数据，），不带任何body信息，如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。（在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。）
HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）

HTTP1.1和HTTP2.0的区别：

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求
HTTP2.0对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
HTTP2.0引入了server push，它允许服务端提前推送相关响应给浏览器

Socket和http的区别

socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉
http连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断开等待下次连接

对称加密与非对称加密

对称密钥加密是指加密和解密使用同一个密钥的方式
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；

Get和Post的区别

功能不同：
get是从服务器上获取数据。
post是向服务器传送数据。
传输数据方式不同：
Get请求的数据会附加到URL中，传输数据的大小受到url的限制。
post在发送数据前会先将请求头发送给服务器进行确认，然后才真正发送数据。
安全性不同
get安全性非常低。
post安全性较高。

网络攻击

CSRF

攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令

解决办法：在请求地址中添加 token 并验证；

SYN攻击

SYN攻击即利用TCP协议缺陷，通过发送大量的半连接请求，占用半连接队列，耗费CPU和内存资源。

优化：

缩短SYN Timeout时间
记录IP，若连续受到某个IP的重复SYN报文，从这个IP地址来的包会被一概丢弃。

转发和重定向

转发是服务器行为。服务器直接向目标地址访问URL,将相应内容读取之后发给浏览器，用户浏览器地址栏URL不变，转发页面和转发到的页面可以共享request里面的数据。

重定向是利用服务器返回的状态码来实现的，如果服务器返回301或者302，浏览器收到新的消息后自动跳转到新的网址重新请求资源。用户的地址栏url会发生改变，而且不能共享数据。