目录
[TCP VS UDP](#TCP VS UDP)
[Tcp 状态机](#Tcp 状态机)
[TCP/ UDP /socket /http /webSocket 区别](#TCP/ UDP /socket /http /webSocket 区别)
[RPC 和 RMI](#RPC 和 RMI)
[Web Service](#Web Service)
[SOAP（Simple Object Access Protocol：简单对象访问协议）](#SOAP（Simple Object Access Protocol：简单对象访问协议）)
[Http 的报文协议结构](#Http 的报文协议结构)
[Post 接口，用 get 请求，收到的状态码是多少？](#Post 接口，用 get 请求，收到的状态码是多少？)
[400 和 500 的状态码有什么区别？](#400 和 500 的状态码有什么区别？)
[Http VS Https](#Http VS Https)
[浏览器中输入："www.xxx.com" 之后都发生了什么？请详细阐述。](#浏览器中输入：“www.xxx.com” 之后都发生了什么？请详细阐述。)
OSI七层 协议 模型
OSI（Open System Interconnection）参考模型，
是参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系。
功能 协议
应用层：针对特定应用协议 ； HTTP FTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP、RTSP
表示层：设备固有格式转换成网络标准；数据安全、压缩。格式有，JPEG、ASCll、DECOIC、加密格式
会话层：建立、管理、终止会话； LDAP、SSH
传输层：两个主机之间数据传输; TCP UDP，tls ； 单位： 数据段（segment)
网络层：地址管理和路由选择； IP（IPV4 IPV6） ；单位：package
数据链路层：互联设备之间传送和识别数据帧；wifi。; 单位：frame
物理层：比特流和电子信号之间切换；以太网、光纤; 单位：bit
1byte=8bit
参考链接：图解OSI七层模型 - 简书
https://zhuanlan.zhihu.com/p/364036628
TCP/IP协议
TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的通信协议，
数据在传输前要建立连接，传输完毕后还要断开连接，
客户端在收发数据前要使用 connect() 函数和服务器建立连接。
建立连接的目的是保证IP地址、端口、物理链路等正确无误，为数据的传输开辟通道。
- 序号 （sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，
发起方发送数据时对此进行标记。
- 确认号 （acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，
确认序号字段才有效，Ack=Seq+1。
（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：
(SYN, FIN, ACK, PSH, RST, URG)
SYN表示建立连接，FIN表示关闭连接，ACK表示响应，
PSH表示有 DATA数据传输，RST表示连接重置。
3次握手
客户端和服务端
- 客户端给服务端发了一个syn(序号) ; 喂，听的见吗？。
- 服务端收到后发送一个syn(序号) +ack(确认号【序号+1】); 听的见,你能听见我说的话嘛。
- 客户端给服务端发一个ack(确认号); 能听见。
/sɪn/
4次挥手
客户端和服务端
- 客户端给服务端发了一个fin; 我没有话和你讲了。
- 服务端收到后发送一个fin+ack;好的，我知道了。
- 服务端给客户端发一个fin; 我也没有话和你讲了。
- 客户端给服务端发一个ack; 好的，我知道了。
/fɪn/
必看链接：https://zhuanlan.zhihu.com/p/108504297
参考链接：图解OSI七层模型 - 简书
https://zhuanlan.zhihu.com/p/364036628
TCP VS UDP
答：TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，
区别包括：
TCP是面向连接的，UDP是无连接的；
TCP是可靠的，UDP是不可靠的；
TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
TCP是面向字节流的，UDP是面向报文的；
TCP有拥塞控制机制; UDP没有拥塞控制，适合媒体通信；
TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；
TCP和UDP分别对应的常见应用层协议
答：(1). TCP 对应的应用层协议：
FTP ：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。
下载文件，上传主页，都要用到FTP服务。
****Telnet：****它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，
通过这种端口可以提供一种基于DOS模式下的通信服务。
如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。
SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。
如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置
中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
POP3： 它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。
也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），
就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件
（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
****HTTP：****从Web服务器传输超文本到本地浏览器的传送协议。
(2). UDP 对应的应用层协议：
DNS： 用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP： 简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，
无连接的服务就体现出其优势。
TFTP (Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务
Tcp 状态机
TCP状态及其描述如下表。
状态 描述
LISTEN 等待来自远程TCP应用程序的请求
SYN_SENT 发送连接请求后等待来自远程端点的确认。TCP第一次握手后客户端所处的状态
SYN-RECEIVED 该端点已经接收到连接请求并发送确认。该端点正在等待最终确认。
TCP第二次握手后服务端所处的状态
ESTABLISHED 代表连接已经建立起来了。这是连接数据传输阶段的正常状态
FIN_WAIT_1 等待来自远程TCP的终止连接请求或终止请求的确认
FIN_WAIT_2 在此端点发送终止连接请求后，等待来自远程TCP的连接终止请求
CLOSE_WAIT 该端点已经收到来自远程端点的关闭请求，此TCP正在等待本地应用程序的连接终止请求
CLOSING 等待来自远程TCP的连接终止请求确认
LAST_ACK 等待先前发送到远程TCP的连接终止请求的确认
TIME_WAIT 等待足够的时间来确保远程TCP接收到其连接终止请求的确认
原文链接：TCP的有限状态机_tcp有限状态机是什么-CSDN博客
TCP / UDP / socket / http / webSocket 区别
-
TCP/UDP工作在传输层，http websocket工作在应用层。
-
socket本身不是一种协议,而是对传输层中的 TCP/UDP协议进行了封装，
对用户隐藏了内部TCP/UDP是如何传输的，只提供一套接口（API）给程序员调用，
从而完成socket编程。通过socket接口，我们才能使用TCP/UDP协议。
- 我们通常浏览网页用到的http协议，是建立在TCP协议之上的一种应用层协议。
RPC 和 RMI
RPC（Remote P rocedure Call 远程过程调用）和RMI（ Remote Method Invocation 远程方法调用）
是两种可以让用户从一台电脑调用不同电脑上面的方法的的机制（也可以称作规范、协议）。
RPC: (Remote Procedure Call) 采用客户端/服务器方式(请求/响应)，发送请求到服务器端，
服务端执行方法后返回结果。优点是跨语言跨平台，缺点是编译期无法排错，只能在运行时检查。
常见的 RPC 框架：阿里的 Dubbo，微博开源的 Motan，
Google 开源的 gRpc，百度开源的 brpc，蚂蚁金服开源的 sofa-rpc 等。
RPC 组成架构
一个完整的 RPC 架构里包含了四个核心的组件，分别是 Client、Client Stub、Server 以及 Server Stub，
这个 Stub 可以理解为存根。
- Client（客户端）：服务的调用者
- Client Stub（客户端存根）：存放服务端的地址消息，
再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方
- Server（服务端）：服务的提供者
- Server Stub（服务端存根）：接收客户端发送过来的消息，将消息解包，并调用本地的方法
链接：https://juejin.cn/post/7029481269415116813
RMI: (Remote Method Invocation)
是指 Java 语言中的远程方法调用，RMI 中的每个方法都具有方法签名，
RMI 客户端和服务器端通过方法签名进行远程方法调用。
RMI 只能在 Java 语言中使用， 可以把 RMI 看作面向对象的 Java RPC。
能够让在客户端Java虚拟机上的对象像调用本地对象一样调用服务端java 虚拟机中的对象上的方法。
是构建在TCP/IP协议上的一种远程调用方法。
优点是强类型、编译期可检查错误；
缺点是只限于java语言。
RPC与RMI的区别
1：方法调用方式不同：
RMI中是通过在客户端的Stub对象作为远程接口进行远程方法的调用。
每个远程方法都具有方法签名。
如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口(stub)上，
那么这个新方法就不能被RMI客户方所调用。
RPC中是通过网络服务协议向远程主机发送请求，请求包含了一个参数集和一个文本值，
通常形成"classname.methodname(参数集)"的形式。RPC远程主机就去搜索与之相匹配的类和方法，
找到后就执行方法并把结果编码，通过网络协议发回。
2：适用语言范围不同：
RMI只用于Java；
RPC是网络服务协议，与操作系统和语言无关。
3：调用结果的返回形式不同：
Java是面向对象的，所以RMI的调用结果可以是对象类型或者基本数据类型；
RMI的结果统一由外部数据表示 (External Data Representation, XDR) 语言表示，
这种语言抽象了字节序类和数据类型结构之间的差异。
RPC 与 HTTP、RMI、Web Service 都能完成远程调用。
原文链接：https://blog.csdn.net/qq_35642036/article/details/83049802
Web Service
Web Service(也叫XML Web Service) 是一种基于 Web 进行服务发布、查询、调用的架构方式，
重点在于服务的管理与使用。Web Service 一般通过 WSDL 描述服务，
使用 SOAP（简单对象访问协议）通过 HTTP 调用服务。 RPC 是一种远程访问协议，
而 Web Service 是一种体系结构，Web Service 也可以通过 RPC 来进行服务调用，
因此 Web Service 更适合同一个 RPC 框架进行比较。
当 RPC 框架提供了服务的发现与管理，并使用 HTTP 作为传输协议时，其实就是 Web Service。
相对 Web Service，RPC 框架可以对服务进行更细粒度的治理，
包括流量控制、SLA 管理等，在微服务化、分布式计算方面有更大的优势。
什么是RMI，什么是RPC，两者之间的区别是什么？_阐述java rmi体系结构,并描述rmi和rpc的关系-CSDN博客
轻量级的独立的通讯技术。是通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，
并通过UDDI进行注册。WebService是一种跨编程语言和跨操作系统平台的远程调用技术。
WebService三要素：
- SOAP (简易对象访问协议)
- UDDI (通用描述、发现及整合)
- WSDL (Web services 描述语言)
优点：
- 跨平台调用
- 跨语言调用
- 远程调用
webservice是一种标准，他可以通过soap或rest的方式来实现。
SOAP（Simple Object Access Protocol：简单对象访问协议）
WebService通过HTTP协议发送请求和接收结果时，
发送的请求内容和结果内容都采用XML格式封装，并增加了一些特定的HTTP消息头，
以说明HTTP消息的内容格式，这些特定的HTTP消息头和XML内容格式就是SOAP协议。
SOAP提供了标准的RPC(远程调用技术)方法来调用Web Service。
SOAP协议组成：SOAP协议 = HTTP协议 + XML数据格式
SOAP协议定义了SOAP消息的格式，SOAP协议是基于HTTP协议的，SOAP也是基于XML的，
XML是SOAP的数据编码方式。
HTTP
HTTP（HyperText Transfer Protocol）(超文本传输协议)是应用层通信协议，
使用标准语义访问指定资源（图片、接口等）， 网络中的中转服务器能识别协议内容。
HTTP 协议是一种资源访问协议，通过 HTTP 协议可以完成远程请求并返回请求结果。
HTTP 的优点 是简单、易用、可理解性强且语言无关 ，在远程服务调用中包括微博有着广泛应用。
HTTP 的缺点 是协议头较重， 一般请求到具体服务器的链路较长，可能会有 DNS 解析、Nginx 代理等。
RPC 是一种协议规范，可以把 HTTP 看作是一种 RPC 的实现，
也可以把 HTTP 作为 RPC 的传输协议来应用。 RPC 服务的自动化程度比较高，
能够实现强大的服务治理功能，和语言结合更友好，性能也十分优秀。
与 HTTP 相比， RPC 的缺点就是相对复杂，学习成本稍高。
HTTP 是一个基于 TCP/IP 通信协议来传递数据的（HTML 文件、图片文件、查询结果等）。
HTTP方法有哪些？
GET： 获取资源；是用来请求URL指定的资源。指定资源经服务器端解析后返回响应内容。
POST： 传输实体主题 ；用来传输实体的主体/用于将数据发送到服务器以创建或更新资源。
PUT：传输文件;像FTP协议的文件上传一样，要求在请求报文主体中包含文件的内容，
然后保存到请求URL指定的位置。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
HEAD：获得报文首部；与GET方法类似，只是不返回报文主体，
用于确认URL的有效性及资源更新的日期时间等。
OPTIONS：询问支持的方法 ****;****用来查询针对请求URL指定的资源支持的方法。
TRACE:追踪路径。
CONNECT:要求用隧道协议链接代理。
说明：
GET请求是可以缓存的，我们可以从浏览器历史记录中查找到GET请求，
还可以把它收藏到书签中；且GET请求有长度限制，仅用于请求数据（不修改）。
注：因GET请求的不安全性，在处理敏感数据时，绝不可以使用GET请求。
Http 的报文协议结构
HTTP 报文协议分为请求报文和响应报文，二者结构相似但也有区别。
请求报文
- 请求行：是请求报文的第一行，包含请求方法、请求 URI 和 HTTP 协议版本。
请求方法常见的有 GET、POST、PUT、DELETE 等，分别用于不同的操作，
如 GET 用于获取资源，POST 用于提交数据。请求 URI 指明了请求资源的路径，
协议版本如 HTTP/1.1 或 HTTP/2 等，决定了报文的格式规范和处理方式。
- 请求头：在请求行之后，包含多个头部字段，用于向服务器传递额外的信息。
例如，User - Agent 字段用于告知服务器客户端的软件信息，包括浏览器类型和版本；
Accept 字段说明客户端可接受的媒体类型，如 text/html、application/json 等；
Host 字段指定了请求的目标主机域名，对于虚拟主机环境很重要。
- 空行：位于请求头之后，用于分隔请求头和请求体，其作用是告诉服务器请求头部分已经结束。
- 请求体：不是所有请求报文都有请求体，常用于 POST 等请求方法。
它包含了客户端向服务器发送的数据，比如在提交表单数据时，
数据就在请求体中，数据格式可以是 application/x - www - form - urlencoded、multipart/form - data 等。
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成
响应报文
- 响应行：位于响应报文的最前端，包含 HTTP 协议版本、响应状态码和响应状态短语。
协议版本与请求报文中的类似，响应状态码是一个三位数字，如 200 表示成功，
404 表示资源未找到，500 表示服务器内部错误等，状态短语是对状态码的简单文字说明。
- 响应头：在响应行之后，包含多个头部字段，向客户端传递服务器的相关信息。
例如，Content - Type 字段说明响应内容的媒体类型，Content - Length 字段告知响应内容的长度，
Set - Cookies 字段用于在客户端设置 Cookie。
- 空行：和请求报文一样，位于响应头之后，用于分隔响应头和响应体。
- 响应体：包含了服务器返回给客户端的实际内容，可能是 HTML 页面、JSON 数据、
图片文件等各种类型的资源，具体内容取决于请求的性质和服务器的处理结果。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
前段请求后端header里有那些属性
请求方式 get、post、put、delete。
Host
Content-Type application/x-www-form-urlencoded;charset:UTF-8，multipart/form-data"： 在文件上载时
- application/xml： XML数据格式
- application/json/pdf/word/form-data/stream
- text/plain纯文本
- text/html/git/png/gif
Connection：keep-alive 表示是否需要持久连接
cookie
content-length 表示这次回包的数据大小，如果数据大小不匹配
User-Agent
说明：HTTP客户端运行的浏览器类型的详细信息。通过该头部信息，
web服务器可以判断到当前HTTP请求的客户端浏览器类别
Accept
说明：指定客户端能够接收的内容类型，
Accept-Language
说明：指定HTTP客户端浏览器用来展示返回信息所优先选择的语言。
Accept-Encoding: gzip,deflate
说明：指定客户端浏览器可以支持的web服务器返回内容压缩编码类型。表示允许服务器在将输出内容发送到客户端以前进行压缩，以节约带宽。而这里设置的就是客户端浏览器所能够支持的返回压缩格式。
HTTP消息中header头部信息的讲解_把所有的头部信息全部粘贴到header中-CSDN博客
Post 接口， 用 get 请求，收到的状态码是多少？
当一个接口定义为 POST 方法，却使用 GET 方法去请求时，
通常会收到 405（Method Not Allowed）状态码。
这是因为服务器理解请求的内容，但不允许使用 GET 方法访问这个特定的资源路径。
服务器端的路由或者处理逻辑是按照接口定义的 POST 方法来配置的，
当收到 GET 请求时，找不到对应的处理方法，所以返回 405 状态码来告知客户端该请求方法不被允许。
400 和 500 的状态码有什么区别？
400 Bad Request（错误请求）
含义：400 状态码表示客户端发送的请求有语法错误，服务器无法理解。
这通常是由于客户端没有按照 API 或者服务器要求的格式发送请求导致的。
常见场景：
- 参数错误：例如在一个 POST 请求中，要求发送 JSON 数据，但是 JSON 格式有误，
如缺少引号、括号不匹配等。
- 请求头错误：如 Content - Type 请求头设置错误，服务器要求发送application/json格式的数据
，而客户端设置为text/plain。
500 Internal Server Error（服务器内部错误）
含义：500 状态码表示服务器在处理请求时遇到了意外的情况，导致无法完成请求。
这是服务器端的错误，和客户端发送的请求本身语法等问题无关。
常见场景：
- 代码错误：服务器端代码出现异常，比如在 Java 程序中，有一个空指针异常（NullPointerException）或者数组越界异常（ArrayIndexOutOfBoundsException）等未被捕获处理，导致服务器无法正常返回数据。
- 数据库连接问题：服务器在处理请求过程中，无法正确连接数据库或者执行数据库操作，如数据库服务器宕机、SQL 查询语句错误等。
HTTPS
HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包，HTTPS 开发的主要目的，
是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
HTTP 的 URL 是由 http:// 起始与默认使用端口 80，
而 HTTPS 的 URL 则是由 https:// 起始与默认使用端口443。
ca证书 (数字证书）+ssl
- 客户端发起HTTPS请求
⽤户在浏览器⾥输⼊⼀个https⽹址，然后连接到server的443端⼝。
- 服务端的配置
采⽤HTTPS协议的服务器必须要有⼀套数字证书，可以⾃⼰制作，也可以向组织申请。
区别就是⾃⼰颁发的证书需要客户端验证通过，才可以继续访问，
⽽使⽤受信任的公司申请的证书则不会弹出提⽰页⾯(startssl就是个不错的选择，有1年的免费服务)。
这套证书其实就是⼀对公钥和私钥。
- 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
- 客户端解析证书
这部分⼯作是有客户端的TLS来完成的，⾸先会验证公钥是否有效，⽐如颁发机构，过期时间等等，
如果发现异常，则会弹出⼀个警告框，提⽰证书存在问题。如果证书没有问题，那么就⽣成⼀个随机值。然后⽤证书对该随机值进⾏加密。就好像上⾯说的，把随机值⽤锁头锁起来，
这样除⾮有钥匙，不然看不到被锁住的内容。
- 传送加密信息
这部分传送的是⽤证书加密后的随机值，⽬的就是让服务端得到这个随机值，
以后客户端和服务端的通信就可以通过这个随机值来进⾏加密解密了。
- 服务端解密信息
服务端⽤私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进⾏对称加密。
所谓对称加密就是，将信息和私钥通过某种算法混合在⼀起，这样除⾮知道私钥，
不然⽆法获取内容，⽽正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥
够复杂，数据就够安全。
- 传输加密后的信息
这部分信息是服务段⽤私钥加密后的信息，可以在客户端被还原。
- 客户端解密信息
客户端⽤之前⽣成的私钥解密服务段传过来的信息，于是获取了解密后的内容。
整个过程第三⽅即使监听到了数据，也束⼿⽆策。
链接：https://wenku.baidu.com/view/2179aa6ecb50ad02de80d4d8d15abe23482f03ad
Http VS Https
答：Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；
Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，
是添加了加密和认证机制的HTTP。二者之间存在如下不同：
端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种共享密钥加密 和公开密钥加密并用的混合加密机制。
SOA P
面向服务的软件架构（Service Oriented Architecture）,
是一种计算机软件的设计模式 ，主要应用于不通应用组件中通过某种协议来互操作
它的基本设计原理是：服务提供了一个简单的接口，抽象了底层的复杂性，
然后用户可以访问独立的服务，而不需要去了解服务底层平台实现。
正因为SOA架构实现不依赖于技术，因此能够被各种不同的技术实现。
因此REST、SOAP、RPC、RMI、DCOM等都是SOA的一种实现而已。
SOAP是微软、IBM等大公司联合制定的一个协议规范。SOAP是交换数据的一种协议规范，
是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，
它被设计成在WEB上交换结构化的和固化的信息。
Socket
Socket是一个网络通信的套接字(接口)
Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API）。
Socket连接需要一对套接字，一个运行于客户端，另一个运行于服务端！
之间的连接分为三个步骤：服务器监听，客户端请求，连接确认。
- 服务器监听：是服务端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，
实时监控网络状态。
- 客户端请求：是由客户端的套接字提出连接请求，要连接的目标是服务端的套接字。
所以客户端的套接字必须首先描述它要连接的服务器的套接字，
指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
- 连接确认：是指当服务器端套接字监听到或者说接收到客户端套接字的连接请求，
它就响应客户端套接字的请求，建立一个新的线程，
把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，连接就建立好了。
而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
https://blog.51cto.com/u_13571520/6046358
原理
服务器:
a.socket()创建socket对象
b.bind()为socket对象绑定协议,赋予名字
c.listen()监听此socket,将socket从默认主动类型改为被动类型
客户端:
a.socket()创建一个socket对象
b.connect()连接服务器的socket对象
服务器,客户端都可使用read(),write()等函数
【网络编程知识】什么是Socket？概念及原理分析_network socket数量表示什么-CSDN博客
Netty
是一个异步事件驱动 的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。
WebSocket 它与Socket没有任何关系。就好比：Java与JavaScript，雷锋与雷峰塔，
两者没有任何关系！WebSocket也是一种协议，并且也是基于TCP协议的。
web S ocket和http的区别
- WebSocket是双向通信协议 ，模拟Socket协议，可以双向发送或接受信息，而HTTP是单向的；
- WebSocket是需要浏览器和服务器握手进行建立连接的，而http是浏览器发起向服务器的连接。
REST / Restful
Rest 风格接口什么意思？
REST（Representational State Transfer）风格接口是一种基于 HTTP 协议的软件架构风格，
用于设计网络应用程序的接口。
从资源角度看，REST 将一切都视为资源，如用户、订单、文章等。
每个资源都有一个唯一的 URI（统一资源标识符），通过对这些 URI 进行操作来访问和处理资源。
例如，获取所有用户信息的 URI 可能是 "/users"，
获取特定用户信息的 URI 可能是 "/users/{user_id}"。
在操作方法上，REST 充分利用 HTTP 协议中的方法来表示对资源的操作。
常用的 HTTP 方法包括 GET 用于获取资源、POST 用于创建资源、
PUT 用于更新资源、DELETE 用于删除资源。
比如，通过发送一个 GET 请求到 "/articles/{article_id}"，可以获取指定文章的内容。
数据传输方面，REST 风格接口通常使用通用的格式，如 JSON 或 XML。
这些格式具有跨平台、跨语言的特性，方便不同系统之间的数据交换。
当客户端请求资源时，服务器会将资源数据以 JSON 或 XML 的形式返回。
从无状态性来看，REST 风格接口是无状态的。
这意味着服务器不会在多个请求之间保存客户端的状态信息，
每个请求都独立包含了处理所需的全部信息。
这样设计的好处是增强了系统的可伸缩性和可维护性，
因为服务器不需要额外的资源来管理客户端状态。
总的来说，REST 风格接口以资源为中心，利用 HTTP 协议的特性，
提供了简洁、统一、高效的接口设计方式，广泛应用于 Web 服务和分布式系统中。
而是一种接口、服务、系统之间通讯的 风格。不是标准，我可以遵守，也可以不遵守！！！
- RESTful是面向资源的，所以接口都是一些名词，尤指复数名词。简单的CRUD还是很合适的，
- 但很多业务逻辑都很难将其抽象为资源。比如说登录/登出，怎么看也不是一个资源，
如果硬是抽象为创建一个session/删除一个session。这不仅反直觉，还违背了RESTful的思想。
- RESTful只提供了基本的增删改查，对于复杂的逻辑是一点办法没有，比如批量下载、批量删除等。
对于复杂的查询，更是无从下手。而且开发时会面临诸多选择，
修改资源用PUT还是PETCH？采用查询参数还是用body？
RESTful是基于REST构建的API就是Restful风格
RESTful就是REST，是REST的形容词形式，可以理解为"REST的"。
例如:colorful和beautiful这两个单词，是"多彩的"和"美丽的"的意思，
因此RESTful API，指的就是很REST风格的API。
1.路径设计
--->在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，
而且所用的名词往往与数据库的表名对应，一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。
--->举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，
则它的路径应该设计成下面这样。
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees
-
- 不用下杠 _ 。比如邀请码写成 invitation-code 。
- API。当我们的 API 发生了重大改变而不兼容前期版本的时候，
- URL 来实现版本化，比如 http://api.example.com/v1、http://apiv1.example.com 。
2.HTTP动词设计
对于资源的具体操作类型，由HTTP动词表示，常用的HTTP动词如下：
请求方式 含义
GET 获取资源（一项或多项）
POST 新建资源
PUT 更新资源（客户端提供改变后的完整资源）
DELETE 删除资源
如何通过路径和http动词获悉要调用的功能：
请求方式 含义
GET /zoos 列出所有动物园
POST /zoos 新建一个动物园
GET /zoos/ID 获取某个指定动物园的信息
PUT /zoos/ID 更新某个指定动物园的信息（提供该动物园的全部信息）
DELETE /zoos/ID 删除某个动物园
GET /zoos/ID/animals 列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID 删除某个指定动物园的指定动物
举个反例：
generalcode.cn/va/deleteFriends 该接口用来表示删除朋友，这就是不符合REST协议的接口。
不能用deleteFriends ，而应该就用friends + http请求的delete方式。
一般接口的返回值绝大部分是JSON类型的。
总结：
看Url就知道要什么
看http method就知道干什么
看http status code就知道结果如何
风格好处：****前后端分离。****前端拿到数据只负责展示和渲染，不对数据做任何处理。
后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，
在web，ios，android三端都可以用相同的接口，是不是很爽？
rest和restful的区别_rest风格和restful风格区别-CSDN博客
浏览器中输入："www.xxx.com" 之后都发生了什么？请详细阐述。
最优解：
前端请求接口发送到后端的完整流程如下：
前端发起请求。
前端代码通过浏览器的 API（如 XMLHttpRequest 或 fetch API）构建请求，
确定目标后端接口的 URL、请求方法、请求头和请求体。
例如，使用 fetch API 时，会按照业务需求编写相应的请求代码。
接着是 DNS 查询。
当请求的 URL 中包含域名时，客户端会先向本地 DNS 服务器发送查询请求。
本地 DNS 服务器会查看缓存，
如果缓存中有该域名对应的 IP 地址，则直接返回；
若没有，则本地 DNS 服务器会向上一级 DNS 服务器发起查询，
直到找到目标域名对应的 IP 地址，这个过程是为了将域名解析为网络中实际通信的 IP 地址。
然后是建立 TCP 连接，也就是三次握手。
客户端向服务器发送一个带有 SYN 标志的 TCP 报文段，序列号为随机数 x，
此时客户端进入SYN_SENT 状态。
服务器收到后，向客户端返回一个 SYN 和 ACK 标志都有的报文段，
序列号为随机数 y ，确认号为 x + 1，服务器进入 SYN_RCVD 状态 。
客户端收到该报文段后，再向服务器发送一个带有 ACK 标志的报文段，
确认号为y + 1， 此时客户端和服务器都进入 ESTABLISHED 状态，三次握手完成，成功建立 TCP 连接。
之后，请求通过网络传输。遵循 HTTP 协议，请求从前端客户端经网络设备（路由器、交换机等）传输到后端服务器。
后端接收请求。后端服务器上的应用程序（基于不同框架构建）通过监听指定端口接收请求，
并将其路由到对应的处理程序或控制器方法。
后端处理请求。在相应的处理程序中解析请求头和请求体，获取数据和参数，
若涉及数据库操作，会进一步查询数据库、执行逻辑操作。
后端响应请求。后端根据处理结果构建响应，包括设置状态码、响应头和响应体，然后将响应发送回前端。
关闭 TCP 连接，即四次挥手。
客户端向服务器发送一个带有 FIN 标志的报文段，此时客户端进入 FIN_WAIT_1 状态。
服务器收到后，向客户端发送 ACK 标志的报文段，服务器进入 CLOSE_WAIT 状态，
客户端收到 ACK 后进入 FIN_WAIT_2 状态。接着服务器向客户端发送带有 FIN 标志的报文段，
进入 LAST_ACK 状态。
客户端收到后，向服务器发送 ACK 标志的报文段，经过一段时间后，客户端和服务器都关闭连接。
前端接收到响应后，根据状态码和响应体中的数据来更新页面或执行其他操作。
解析：经典的网络协议问题。
- 由域名→IP地址 寻找IP地址的过程依次经过了浏览器缓存、系统缓存、hosts文件、
路由器缓存、 递归搜索根域名服务器。
- 建立TCP/IP连接（三次握手具体过程）
- 由浏览器发送一个HTTP请求
- 经过路由器的转发，通过服务器的防火墙，该HTTP请求到达了服务器
- 服务器处理该HTTP请求，返回一个HTML文件
- 浏览器解析该HTML文件，并且显示在浏览器端
这里需要注意：
HTTP协议是一种基于TCP/IP的应用层协议，进行HTTP数据请求必须先建立TCP/IP连接
可以这样理解：HTTP是轿车，提供了封装或者显示数据的具体形式；
Socket 是发动机，提供了网络通信的能力 。两个计算机之间的交流无非是两个端口之间的数据通信,
具体的数据会以什么样的形式展现是以不同的应用层协议来定义的。
前端请求接口发送到后端的流程如下：
前端发起请求。首先，在前端代码中，通过浏览器提供的 API（如 XMLHttpRequest 或 fetch API）构造请求。这需要确定请求的目标地址（即后端接口的 URL）、请求方法（GET、POST 等）、请求头（包含如内容类型、认证信息等）和请求体（如果是 POST 或 PUT 等需要发送数据的请求）。例如，在 JavaScript 中使用 fetch API 时，会编写类似fetch('http://backend - api.com/data', {method: 'GET', headers: {'Content - Type': 'application/json'}})的代码。
接着，请求从前端发出，经过网络传输。请求会通过互联网或本地网络，遵循 HTTP 协议（或其他协议），从前端客户端（如浏览器）发送到后端服务器。在此过程中，请求可能会经过网络设备（如路由器、交换机等），这些设备会协助将请求路由到目标服务器。
然后，后端接收请求。后端服务器上运行的应用程序（如基于 Spring Boot、Flask 等框架构建的应用）通过监听指定端口，接收到前端的请求。服务器端会根据请求的 URL 和请求方法，将请求路由到对应的处理程序或控制器方法。
之后，后端处理请求。在对应的处理程序中，会解析请求头和请求体，获取请求中的数据和参数。如果是数据库驱动的应用，可能会进一步查询数据库、执行业务逻辑操作，如验证用户身份、处理订单数据等。
最后，后端响应请求。后端根据处理结果构造响应，包括设置响应状态码（如 200 表示成功，404 表示未找到资源等）、响应头（包含如内容类型、缓存信息等）和响应体（包含处理结果数据），然后将响应发送回前端。前端接收到响应后，根据状态码和响应体中的数据来更新页面或执行其他操作。
B/S和C/S区别
Client/Server(客户端/服务器)架构，Brower/Server(浏览器/服务器)架构
1、建立基础不同
C/S是建立在局域网的基础上的；而，B/S是建立在广域网的基础上的。
2、硬件环境不同
C/S 一般建立在专用的网络上，小范围里的网络环境，
局域网之间再通过专门服务器提供连接和数据交换服务。
B/S 建立在广域网之上的，不必有专门的网络硬件环境，
例与电话上网，租用设备，信息自己管理。有比C/S更强的适应范围,一般只要有操作系统和浏览器就行。
- 对安全要求不同
C/S 一般面向相对固定的用户群，对信息安全的控制能力很强。
一般高度机密的信息系统采用C/S 结构适宜，可以通过B/S发布部分可公开信息.
B/S 建立在广域网之上， 对安全的控制能力相对弱， 面向是不可知的用户群。
4、对程序架构不同
C/S 程序更加注重流程， 可以对权限多层次校验， 对系统运行速度可以较少考虑。
B/S对安全以及访问速度的多重考虑， 建立在需要更加优化的基础之上。
比C/S有更高的要求 B/S结构的程序架构是发展的趋势，从MS的。
Net系列的BizTalk 2000 Exchange 2000等， 全面支持网络的构件搭建的系统。
SUN 和IBM推的JavaBean 构件技术等，使 B/S更加成熟。
例如智赢IPOWER，采用AJAX和数据存储优化技术，相比一般B/S架构软件速度提高30%至99%。