标签：从服务器 nts rest api ftp 硬件 很多 ESS range 网络流
OSI模型，即开放式通信系统互联参考模型(Open System Interconnection）
1，OSI七层协议分别：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
2，TCP/IP五层模型的协议：物理层、数据链路层、网络层、传输层、应用层。
物理层：是我们传输信息的一些介质，在物理媒介上透明传输bit流，比如双绞线、网线等
数据链路层：数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。
网络层：在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。
传输层：能在两台计算机之间够建立端到端的连接，进行数据的传输和理解
应用层：应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。
问题1：什么是HTTP协议？
客户端和服务器端之间数据传输的格式规范，格式简称为“超文本传输协议”。
基于TCP协议，默认使用80端口。
问题2：什么是Http协议无状态协议?怎么解决Http协议无状态协议?
无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
无状态协议解决办法： 通过1、Cookie 2、通过Session会话保存。
Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。
Cookie是一种存在的数据，session是一种概念。一般我们用cookie实现session。
http方法
1、GET方法
GET方法用于使用给定的URI从给定服务器中检索信息，即从指定资源中请求数据。使用GET方法的请求应该只是检索数据，并且不应对数据产生其他影响。
在GET请求的URL中发送查询字符串（名称/值对），需要这样写：
|
1 |
/test/demo_form.php?name1=value1&name2=value2 |
说明：
GET请求是可以缓存的，我们可以从浏览器历史记录中查找到GET请求，还可以把它收藏到书签中；且GET请求有长度限制，仅用于请求数据（不修改）。
注：因GET请求的不安全性，在处理敏感数据时，绝不可以使用GET请求。
2、POST方法
POST方法用于将数据发送到服务器以创建或更新资源，它要求服务器确认请求中包含的内容作为由URI区分的Web资源的另一个下属。
POST请求永远不会被缓存，且对数据长度没有限制；我们无法从浏览器历史记录中查找到POST请求。
3、HEAD方法
HEAD方法与GET方法相同，但没有响应体，仅传输状态行和标题部分。这对于恢复相应头部编写的元数据非常有用，而无需传输整个内容。
4、PUT方法
PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。
它会将包含的元素放在所提供的URI下，如果URI指示的是当前资源，则会被改变。如果URI未指示当前资源，则服务器可以使用该URI创建资源。
5、DELETE方法
DELETE方法用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容。
6、CONNECT方法
CONNECT方法用来建立到给定URI标识的服务器的隧道；它通过简单的TCP / IP隧道更改请求连接，通常实使用解码的HTTP代理来进行SSL编码的通信（HTTPS）。
7、OPTIONS方法
OPTIONS方法用来描述了目标资源的通信选项，会返回服务器支持预定义URL的HTTP策略。
8、TRACE方法
TRACE方法用于沿着目标资源的路径执行消息环回测试；它回应收到的请求，以便客户可以看到中间服务器进行了哪些（假设任何）进度或增量。
请求报文：
1）请求行： 请求方法（get/post） 请求资源路径URL 协议类型和版本（http/1.0）
2）请求头： 消息头是一些键值对，一般由w3c定义，浏览器与web服务器之间都可以发送，表示特定的某种含义，比如，浏览器可以发送"user-agent"消息头，告诉web服务器浏览器的类型和版本。
3）请求数据： 只有当请求方式为post时才有值(请求参数)，如果请求方式为get，请求参数会添加到请求资源路径的后面。
响应报文：
1）响应行：协议类型和版本（http/1.0） 状态码 状态描述（OK）
2）响应头： 服务器也可以发送一些消息头给浏览器，比如"content-type",告诉浏览器，服务器返回的数据类型和编码格式(字符集)。
3）响应正文：程序处理的结果,浏览器会将实体内容中的数据取出来，生成相应的页面。
通用首部字段：Date：创建报文时间；Cache-Control：缓存的控制；
请求首部字段：Host：请求资源所在服务器；Accept：可处理的媒体类型Accept-Charset：可接收的字符集；Accept-Encoding：可接受的内容编码；Accept-Language：可接受自然语言
响应首部字段：Location：令客户端重新定向到的URI
实体首部字段：Content-Type：实体主类类型；Content-Encoding：实体主体适用的编码方式
200：OK 客户端请求成功
301：永久性重定向，使用域名跳转
302：临时重定向，未登录用户访问用户中心重定向到登录页面
304：客户端浏览器的缓存内容没有过期，服务器没有重新发送该网页内容给客户端。
403：服务器收到请求，但是拒绝提供服务，请求的对应资源禁止被访问
404：服务器无法找到对应资源
500：服务器内部错误
503：服务器正忙
1）默认持久连接 节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求，不用声明Connection: keep-alive
2）管道机制，即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。举例：客户端需要请求两个资源。以前的做法是，同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后在发出B请求。管道机制允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。必须加Content-Length: 字段说明第一个回应多长，这样就知道第二个回应从哪开始。
HTTP1.0最早在网页中使用是在1996年。
而HTTP1.1在1999年才开始广泛应用，HTTP1.1也是当前使用最为广泛的HTTP协议。
1. 缓存处理：HTTP/1.0 使用 Pragma:no-cache + Last-Modified/If-Modified-Since来作为缓存判断的标准；HTTP/1.1 引入了更多的缓存控制策略：Cache-Control、Etag/If-None-Match等。
2. 错误状态管理：HTTP/1.1新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 范围请求：HTTP/1.1在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接，支持断点续传。
4. Host头：HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。
5. 持久连接：HTTP/1.1 最大的变化就是引入了持久连接（persistent connection），在HTTP/1.1中默认开启 Connection: keep-alive，即TCP连接默认不关闭，可以被多个请求复用。
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。
6. 管道机制：HTTP/1.1中引入了管道机制（pipelining）,即在同一个TCP连接中，客户端可以同时发送多个请求。
HTTP2.0在性能上有了很大的提升，它的主要改动和优化列举如下：
HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，如下图所示，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。
1）get重点在从服务器上获取资源，post重点在向服务器发送数据；
2）get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，如
http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
3）Get传输的数据量小，因为受URL长度限制，但效率较高；
Post可以传输大量数据，所以上传文件时只能用Post方式；
4）get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；
5）get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
post支持标准字符集，可以正确传递中文字符。
1，端口号：用来标识同一台计算机的不同应用进程。计算机网络通过端口号实现复用/分用
1）源端口：源端口和IP地址的作用是标识报文的返回地址。
2）目的端口：端口指明接收方计算机上的应用程序接口。
TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。
2，序号和确认号：是TCP可靠传输的关键部分。
序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。
序列号等于前一个报文段的序列号与前一个报文段中数据字节的数量之和。
确认号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。即序列号+1；当然前面需要重传的就不是加1了。
确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。
3，控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。
1）URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。
2）ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。
3）PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。
4）RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。
5）SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
6）FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。
4，窗口：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。
5，校验和：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。由发送端计算和存储，并由接收端进行验证。
6，选项和填充：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项， 它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。
7，数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。 如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段
1、源端口号：发送端端口号（16位）
2、目的端口号：接收端端口号（16位）
3、用户数据报长度：包括报头和用户数据在内的总字节数。（16位）
4、校验和：对报头和用户数据进行校验。（16位）
在linux中结构体如下所示：
/usr/include/udp.h
struct udphdr {
__be16 source; //源端口号
__be16 dest; //目的端口号
__be16 len; //用户数据报长度
__sum16 check; //校验和
};
补充：因为传输层主要解决的问题是端到端通信，网络层主要解决的是点到点通信，所以传输层只需要端口号，而具体点到点的连接由下层网络层提供
一方面因为发送数据的时候，报文在传输层【分组后】，报文段将在网络层被打上IP的协议头（形成数据包），此时端口+IP已经组成，唯一确定一台机器的一个进程。 相反，在接收数据的时候，首先通过IP唯一定位一台机器（局域网临时IP唯一，广域网公网IP唯一），并在数据包传至传输层的时候对数据包进行拆包，形成报文段，此时报文段只需要端口即可， 因为具体的机器在网络层已经确定，而此时使用端口确定具体的进程（应用）即可
1）有连接/无连接
2）可靠/不可靠（不能保证都送达）
3）面向字节流/面向报文（UDP数据传输单位是报文，不会对数据进行拆分和拼接操作，只是给上层传来的数据加个UDP头或者给下层来的数据去掉UDP头）
4）有拥塞控制/没有拥塞控制，始终以恒定速率发送数据
5）每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。6）TCP首部开销至少20字节;UDP的首部开销小，只有8个字节。
三次握手的目的是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。
四次挥手，由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就只能发送一个FIN来终止这个方向的连接。
收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
(1). 三次握手(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)：
第一次握手：客户端将标志位SYN置为1，随机产生一个序列号seq=x，并将该数据包发送给服务端，客户端进入SYN_SENT状态，等待服务端确认。
第二次握手：服务端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务端将标志位SYN和ACK都置为1，ack=x+1，随机产生一个序列号seq=y，并将该数据包发送给客户端以确认连接请求，服务端进入SYN_RCVD状态。
第三次握手：客户端收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给服务端，服务端检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，客户端和服务端进入ESTABLISHED状态，完成三次握手，随后客户端与服务端之间可以开始传输数据了。
四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：
第一次挥手：客户端发送一个标志位FIN，序列号 u，用来关闭客户端到服务端的数据传送，客户端进入终止等待FIN_WAIT_1状态。
第二次挥手：服务端收到标志位FIN后，发送一个标志位ACK给客户端，确认序号ack为收到序号seq+1（与SYN相同，一个FIN占用一个序号），服务端进入关闭等待CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
第三次挥手：服务端发送一个标志位FIN，用来关闭服务端到客户端的数据传送，服务端进入最后确认LAST_ACK状态。
第四次挥手：客户端收到FIN后，客户端进入时间等待TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。
1）例： TCP建立连接的过程采用三次握手，已知第三次握手报文的发送序列号为1000，确认序列号为2000，请问第二次握手报文的发送序列号和确认序列号分别为？
第一次握手：客户端：发送X
第二次握手：服务端：发送Y， 确认X+1
第三次握手：客户端：发送X+1（1000），确认Y+1（2000）
可以反推第二次序列号为1999,确认1000
客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。Syn攻击是一个典型的DDOS攻击。
检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时（syn_recv），特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击netstat -n -p TCP | grep SYN_RECV
3）TIME_WAIT状态有两个存在的理由。
a）保证发送的ACK会成功发送到对方，
b）报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。
MSL即Maximum Segment Lifetime，也就是报文最大生存时间
1、客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，
（1）首先会在浏览器缓存中去查询，之前每浏览一个网站，浏览器都会在缓存中存有域名与ip地址的映射关系。不过缓存失效的时间不由浏览器决定，而由操作系统决定。
（2）浏览器缓存中查询不到后，之后会在系统缓存中查询，由浏览器发起一个系统调用，查询系统缓存中的数据。
（3）系统缓存中也查询不到后，将会去路由器缓存中查找。
（4）路由器缓存中也找不到的话，将会从本地DNS服务器的缓存中查找，本地服务器即用户自己配置的DNS服务器。
（5）如果本地的DNS服务器也找不到的话，本地DNS将会发送请求至根域名服务器，根域名服务器中没有相关缓存数据的时候，就会返回com顶级域名服务器的地址。然后本地DNS服务器再发送请求至com顶级域名服务器，com顶级域名服务器中查询不到的话，就会返回baidu权威服务器的地址，然后本地DNS服务器再发送请求至baidu权威服务器，baidu权威服务器就会返回www主机地址。（这是一种迭代的过程，还有一种递归的过程。即local至根域名，根域名不直接返回com地址，而是发送请求至com，com发送请求至baidu，baidu发送请求至www，www再返回给baidu，baidu返回给com，com再返回给local）至此，整个DNS查询步骤结束，现在浏览器拿到了域名对应的ip地址。
2、通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，浏览器向服务器请求建立链接，发起三次握手；然后通过TCP进行封装数据包，输入到网络层。
3、在客户端的传输层(添加TCP头)，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
4、客户端的网络层（添加IP头）不用关系应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。
5、客户端的链路层（添加MAC头），包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。
6、 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
7. 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
8. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
浏览器通过Ajax（Asynchronous Javascript And XML 异步 JavaScript 和 XML）
9、在传统的web应用，用户每发一次请求，用户的动作就会被阻塞，即在服务器返回响应之前，用户不可以进行其他的操作，只能等待响应。然后服务器会响应一个完整的html页面，浏览器再次进行渲染。哪怕是一个很小的一个请求，都会阻塞用户动作，以及刷新整个页面，极大地浪费了用户的时间和网络的带宽，也增加了服务器的压力。
Ajax出现之后，通过此技术发起的http请求，将不会阻塞用户的动作，服务器响应之后，页面会进行一个局部的刷新，也就是不会刷新整个页面，极大提高了页面加载与服务器处理的效率。当然Ajax也要自身的缺点，暴露了浏览器和服务器通信的具体逻辑，容易造成漏洞攻击。此外，Ajax没有后退机制，在一定程度上，用户的体验感降低。
百度界面显示出来后，百度又利用了ajax去请求我之前的搜索关键词，然后利用js填充到搜索框的下拉列表中，返回的数据如下：
TCP 利用滑动窗口实现流量控制的机制。
滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。
TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。
3.1慢开始
1）开始发送窗口cwnd=1 （即一个最大报文段的长度 MSS），指数增长报文段个数
2）当发送窗口的报文段个数大于等于 慢开始门限（ssthresh=16）时，即从指数增长变为加法增长。即改用拥塞避免算法。
4）如果遇到网络拥塞（超时重传）用快恢复算法，
a）慢开始门限设为当前发送窗口的一半；
b）发送窗口设为慢开始门限；
c）启用拥塞避免算法；
发送窗口 < 慢开始门限：使用慢开始算法
发送窗口 > 慢开始门限：使用拥塞避免算法
当遇到阻塞，则用不再用慢开始，改用快恢复，接着用拥塞避免算法。
3.2.1 快重传原理：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
2.2.2 快恢复原理：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh（慢开始门限）的大小，然后执行拥塞避免算法。
ARP（Address Resolution Protocol）即地址解析协议， 用于实现从 IP 地址到 MAC 地址的映射，即询问目标IP对应的MAC地址。
Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：
端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
一、如何选择免费SSL证书？
建议选择Let’s Encrypt。Let’s Encrypt免费SSL证书虽然只有90天，支持手动和自动续期。Let’s Encrypt SSL在各大浏览器上都得到认可，是免费SSL证书的首选。
Let’s Encrypt适用于VPS等有独立IP的主机上，但是这个免费证书在虚拟主机上使用不是很方便。
现在七牛、阿里云、腾讯云等都提供免费的SSL服务，通过简单的设置就可以配置成功。建议优先使用这些网站提供的免费SSL服务，简单好用。
二、服务器开启HSTS
采用 HSTS 协议的网站将保证浏览器始终连接到网站的HTTPS版本，而不需要用户手动在URL地址栏中输入包含https://的加密地址。我用的是Nginx 服务器，只需要编辑 Nginx 配置文件（如：/usr/local/nginx/conf/nginx.conf）将下面行添加到 HTTPS 配置的 server 块中即可：
三、开启HTTP/2和OCSP Stapling
HTTP/2 相比于之前的HTTP/1.1 在性能上的大幅度提升，所以只要你启用了Https，记得一定要开启HTTP/2，检查一下你的配置文件是否有：listen 443 ssl http2;
OCSP Stapling 服务器事先模拟浏览器对证书链进行验证，然后将 OCSP 验证结果缓存到本地。这样，当浏览器访问站点时，在握手阶段，可以直接拿到 OCSP 响应结果和证书链，对访问速度有明显提升。
四、使用ECC和RSA双证书
默认的我们都会使用RSA证书，因为RSA证书的兼容性最为广泛。但是ECC 证书拥有体积小、运算速度快、安全性高（256位ECC key就能起到相当于3072位的RSA key的安全性）等特点，可以在一定程度上提供Https性能。
五、 开启DNS CAA
DNS CAA的作用是只允许在记录中列出的 CA 机构颁发针对该域名(或子域名)的证书，以防止有人伪造SSL证书，同时CAA 记录可以控制单域名 SS L证书的发行，也可以控制通配符证书。详细方法见：京东云DNS设置CAA。
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。
客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达服务端。这是，服务端误以为这是客户端发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要服务端发出确认数据包，新的链接就建立了。由于客户端此时并未发出建立链接的请求，所以其不会理睬服务端的确认，也不与服务端通信；而这时服务端一直在等待客户端的请求，这样服务端就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于服务端端没有收到来自客户端的确认，则就会知道客户端并没有要求建立请求，就不会建立链接。
TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。
对于可靠性，TCP通过以下方式进行保证：
数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认
1)、DDos 攻击
客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认
2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )
限制同时打开SYN半链接的数目
缩短SYN半链接的Time out 时间
关闭不必要的服务
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
1). SQL注入攻击的总体思路
(1). 寻找到SQL注入的位置
(2). 判断服务器类型和后台数据库类型
(3). 针对不通的服务器和数据库特点进行SQL注入攻击
2). SQL注入攻击实例
比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：
用户名： ‘or 1 = 1 --
密 码：
1
2
用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输入了上面的用户名和密码，上面的SQL语句变成：SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL语句我们知道，
username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。
3). 应对方法
(1). 参数绑定
使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用#和$来获取参数值。当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用$时，变量就是直接追加在sql中，一般会有sql注入问题。
(2). 使用正则表达式过滤传入的参数
客户端收到服务的释放连接的请求后，不是立马进入CLOSE状态，而是还要再等待2MSL。理由是：
客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端返回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接.
新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。
请你简单讲解一下，负载均衡 反向代理模式的优点、缺点
考察点：反向代理
（1）反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
（2）反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
（3）反向代理负载均衡能以软件方式来实现，如apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访问真实的服务器，具备额外的安全性（同理，NAT负载均衡技术也有此优点）。
（4）其缺点主要表现在以下两个方面
反向代理是处于OSI参考模型第七层应用的，所以就必须为每一种应用服务专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对web服务器的负载均衡。
针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
一般来讲，可以用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，如search等。
1、工作层次不同：交换机比路由器更简单，路由器比交换器能获取更多信息
交换机工作在数据链路层，而路由器工作在网络层
2、数据转发所依据的对象不同
交换机的数据转发依据是利用物理地址或者说MAC地址来确定转发数据的目的地址
而路由器是依据ip地址进行工作的
3、传统的交换机只能分割冲突域，不能分割广播域;而路由器可以分割广播域
察点：ICMP协议
参考回答：
它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
考察点：ARP协议
地址解析协议。ARP攻击的第一步就是ARP欺骗。由上述“ARP协议的工作过程”我们知道，ARP协议基本没有对网络的安全性做任何思考，当时人们考虑的重点是如何保证网络通信能够正确和快速的完成——ARP协议工作的前提是默认了其所在的网络是一个善良的网络，每台主机在向网络中发送应答信号时都是使用的真实身份。不过后来，人们发现ARP应答中的IP地址和MAC地址中的信息是可以伪造的，并不一定是自己的真实IP地址和MAC地址，由此，ARP欺骗就产生了。
考察：HTTP加密协议
1、 客户端发出请求
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
2、服务器回应
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。
3、客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
4、服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
子网掩码：
IP地址是以网络号和主机号来标示网络上的主机的，我们把网络号相同的主机称之为本地网络，网络号不相同的主机称之为远程网络主机，本地网络中的主机可以直接相互通信；远程网络中的主机要相互通信必须通过本地网关（Gateway）来传递转发数据。
1、子网掩码的概念及作用
①、子网掩码（Subnet Mask）又叫网络掩码、地址掩码，必须结合IP地址一起对应使用。
②、只有通过子网掩码，才能表明一台主机所在的子网与其他子网的关系，使网络正常工作。
③、子网掩码和IP地址做“与”运算，分离出IP地址中的网络地址和主机地址，用于判断该IP地址是在本地网络上，还是在远程网络网上。
④、子网掩码还用于将网络进一步划分为若干子网，以避免主机过多而拥堵或过少而IP浪费。
为什么要使用子网掩码？
前面说道，子网掩码可以分离出IP地址中的网络地址和主机地址，那为什么要分离呢？因为两台主机要通信，首先要判断是否处于同一网段，即网络地址是否相同。如果相同，那么可以把数据包直接发送到目标主机，否则就需要路由网关将数据包转发送到目的地。
可以这么简单的理解：A主机要与B主机通信，A和B各自的IP地址与A主机的子网掩码进行And与运算，看得出的结果：
1、结果如果相同，则说明这两台主机是处于同一个网段，这样A可以通过ARP广播发现B的MAC地址，B也可以发现A的MAC地址来实现正常通信。
2、如果结果不同，ARP广播会在本地网关终结，这时候A会把发给B的数据包先发给本地网关，网关再根据B主机的IP地址来查询路由表，再将数据包继续传递转发，最终送达到目的地B。
计算机的网关（Gateway）就是到其他网段的出口，也就是路由器接口IP地址。路由器接口使用的IP地址可以是本网段中任何一个地址，不过通常使用该网段的第一个可用的地址或最后一个可用的地址，这是为了尽可能避免和本网段中的主机地址冲突。
所以在这里总结一下：
ipv4有32位，由网络号+主机号构成。
子网掩码的作用：
1.判断两ip地址是否在同一网段。是判断ip地址的网段的必要元素。
2.如果想为ip划分子网，需向ip地址的主机部分借位，借几位，子网掩码也相应的向右移动几位，这样子可以缓解C类地址2^8-2=254个主机数较少，B类地址2^16-2=65534个主机数又过多的尴尬场面（减去的2的情况是本网络的网络地址，全为0的情况，和本网络的广播地址全为1的情况。）。
网关的作用：计算机的网关（Gateway）就是到其他网段的出口，也就是路由器接口IP地址。路由器接口使用的IP地址可以是本网段中任何一个地址，不过通常使用该网段的第一个可用的地址或最后一个可用的地址，这是为了尽可能避免和本网段中的主机地址冲突。
DNS为什么用TCP和UDP
DNS同时占用UDP和TCP端口53是公认的，这种单个应用协议同时使用两种传输协议的情况在TCP/IP栈也算是个另类。但很少有人知道DNS分别在什么情况下使用这两种协议。
先简单介绍下TCP与UDP。
TCP是一种面向连接的协议，提供可靠的数据传输，一般服务质量要求比较高的情况，使用这个协议。UDP—用户数据报协议，是一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。
TCP与UDP的区别：
UDP和TCP协议的主要区别是两者在如何实现信息的可靠传递方面不同。TCP协议中包含了专门的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息；发送方只有在接收到该确认消息之后才继续传送其它信息，否则将一直等待直到收到确认信息为止。 与TCP不同，UDP协议并不提供数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据报的丢失，协议本身并不能做出任何检测或提示。因此，通常人们把UDP协议称为不可靠的传输协议。相对于TCP协议，UDP协议的另外一个不同之处在于如何接收突发性的多个数据报。不同于TCP，UDP并不能确保数据的发送和接收顺序。事实上，UDP协议的这种乱序性基本上很少出现，通常只会在网络非常拥挤的情况下才有可能发生。
既然UDP是一种不可靠的网络协议，那么还有什么使用价值或必要呢？其实不然，在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。
DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议；
DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。
为什么既使用TCP又使用UDP？
首先了解一下TCP与UDP传送字节的长度限制：
UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。
区域传送时使用TCP，主要有一下两点考虑：
1.辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
2.TCP是一种可靠的连接，保证了数据的准确性。
域名解析时使用UDP协议：
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
UDP
UDP 与 TCP 的主要区别在于 UDP 不一定提供可靠的数据传输。事实上，该协议不能保证数据准确无误地到达目的地。UDP 在许多方面非常有效。当某个程序的目标是尽快地传输尽可能多的信息时（其中任意给定数据的重要性相对较低），可使用 UDP。ICQ 短消息使用 UDP 协议发送消息。
许多程序将使用单独的TCP连接和单独的UDP连接。重要的状态信息随可靠的TCP连接发送，而主数据流通过UDP发送。
TCP
TCP的目的是提供可靠的数据传输，并在相互进行通信的设备或服务之间保持一个虚拟连接。TCP在数据包接收无序、丢失或在交付期间被破坏时，负责数据恢复。它通过为其发送的每个数据包提供一个序号来完成此恢复。记住，较低的网络层会将每个数据包视为一个独立的单元，因此，数据包可以沿完全不同的路径发送，即使它们都是同一消息的组成部分。这种路由与网络层处理分段和重新组装数据包的方式非常相似，只是级别更高而已。
为确保正确地接收数据，TCP要求在目标计算机成功收到数据时发回一个确认（即 ACK）。如果在某个时限内未收到相应的 ACK，将重新传送数据包。如果网络拥塞，这种重新传送将导致发送的数据包重复。但是，接收计算机可使用数据包的序号来确定它是否为重复数据包，并在必要时丢弃它。
TCP协议与UDP协议的区别
TCP基于面向连接的协议，数据传输可靠，传输速度慢，适用于传输大量数据，可靠性要求高的场合。
UDP协议面向非连接协议，数据传输不可靠，传输速度快，适用于一次只传送少量数据、对可靠性要求不高的应用环境。
面向连接的TCP
“面向连接”就是在正式通信前必须要与对方建立起连接。比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。
TCP协议能为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地发往网络上的其他计算机，对可靠性要求高的数据通信系统往往使用TCP协议传输数据。
面向非连接的UDP协议
“面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。这与现在风行的手机短信非常相似：你在发短信的时候，只需要输入对方手机号就OK了。
UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境
UDP协议是面向非连接的协议，没有建立连接的过程。正因为UDP协议没有连接的过程，所以它的通信效果高；但也正因为如此，它的可靠性不如TCP协议高。QQ就使用UDP发消息，因此有时会出现收不到消息的情况。
TCP协议与UDP协议支持的应用协议
TCP支持的应用协议主要有：Telnet、FTP、SMTP等；
UDP支持的应用层协议主要有：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（通用文件传输协议）等。
TCP和UDP都是位于OSI模型中的传输层中。
TCP优点:面向连接的,具有实时性,就象打电话一样,两者必须建立连接.
它保证你所传输的东西是准确到达的,并且收方要给你一个收到或没有\ 收到的回复,所以它具有安全性的特点..
UDP优点:面向无连接的,就象给某人寄信一样,对方不需要在邮局等着你的信到.
所以说,它没有保障性,不能确保你一定能收到信,不象TCP那样,,但是 它比TCP好的一点,就是速度快,因为他不需要双方交流是否收到,对发的东西有一个确认的过程.
早期单机时代，一台电脑上运行多个进程，大家各干各的，老死不相往来。假如A进程需要一个画图的功能，B进程也需要一个画图的功能，程序员就必须为两个进程都写一个画图的功能。这不是整人么？于是就出现了IPC（Inter-process communication，单机中运行的进程之间的相互通信）。OK，现在A既然有了画图的功能，B就调用A进程上的画图功能好了，程序员终于可以偷下懒了。
到了网络时代，大家的电脑都连起来了。以前程序只能调用自己电脑上的进程，能不能调用其他机器上的进程呢？于是就程序员就把IPC扩展到网络上，这就是RPC（远程过程调用）了。现在不仅单机上的进程可以相互通信，多机器中的进程也可以相互通信了。
要知道实现RPC很麻烦呀，什么多线程、什么Socket、什么I/O，都是让咱们普通程序员很头疼的事情。于是就有牛人开发出RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）。
OK，现在可以定义RPC框架的概念了。简单点讲，RPC框架就是可以让程序员来调用远程进程上的代码一套工具。有了RPC框架，咱程序员就轻松很多了，终于可以逃离多线程、Socket、I/O的苦海了。
首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
比如说，一个方法可能是这样定义的：
Employee getEmployeeByName(String fullName)
那么：
首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
两台计算机如何实现通信呢？人类交流是通过定义一定的语言，计算机也是，他们之间必须要有相应的协议才可以。
socket通信
在上面其实我们对通讯需要掌握的一些基础知识进行了分析，这里我们开始使用java语言来演示一下这个过程。
socket通信其实是有两种方式：TCP和UDP过程。
（1）TCP是可靠地面向连接的通信过程，含有三次握手四次挥手的机制。
（2）UDP是不可靠的无连接的通信过程，客户端只管发，不管服务端有没有接受到。
那这两种通信方式的基本模型是什么呢？我们使用一张图来看一下：、
1、数据存放位置不同：
cookie数据存放在客户的浏览器上，session数据放在服务器zhi上。
2、安全程度不同：
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
3、性能使用程度不同：
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。
4、数据存储大小不同：
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。
有了cookie情况就不同了，除非我们之前把你的信息记录在cookie里，在你打开网页和服务器建立连接的时候，把cookie记录的你的信息一起发送给服务器，这样服务器就能从cookie接收到的信息里识别你的身份，让页面为你提供特别属于你的内容。
我们访问浏览器的时候，浏览器会发送一个HTTP请求到服务器端；
服务器会发送一个HTTP响应到客户端，其中包括Sst-Cookie，意思就是浏览器建立一个cookie保存服务器指定的内容，比如用户信息和用户操作信息；
浏览器保存好信息之后，下次我们再次访问网站的时候，浏览器再发送HTTP请求到服务器端时都会携带之前保存的cookie；
服务器端会从收到的cookie中识别用户身份，就能让页面为你提供专门属于你的内容了。
比如我们从网站的登陆界面中看到有记住我这个选项，你勾选了它以后，登陆成功，浏览器就会把你的信息放在cookie里，下次再访问这个网站的时候，服务器就能根据收到的cookie识别出是你，帮你自动登陆，显示专属于你的内容。
session在计算机网络应用中被称为“会话控制”。客户端浏览器访问网站的时候
服务器会向客户浏览器发送一个每个用户特有的会话编号sessionID，让他进入到cookie里。服务器同时也把sessionID和对应的用户信息、用户操作记录在服务器上，这些记录就是session。
客户端浏览器再次访问时，会发送cookie给服务器，其中就包含sessionID。
服务器从cookie里找到sessionID，再根据sessionID找到以前记录的用户信息就可以知道他之前操控些、访问过哪里。
session保存在服务器端比较安全，但是可能需要记录千百万用户的信息，对服务器的存储压力很大，所以我们应该有选择的合理使用cookie和session。
TCP是个"流"协议，所谓流，就是没有界限的一串数据。
大家可以想想河里的流水，是连成一片的，其间是没有分界线的。但一般通讯程序开发是需要定义一个个相互独立的数据包的，比如用于登陆的数据包，用于注销的数据包。
由于TCP"流"的特性以及网络状况,在进行数据传输时会出现以下几种情况：
假设我们连续调用两次 send 分别发送两段数据 data1 和 data2，在接收端有以下几种接收情况(当然不止这几种情况,这里只列出了有代表性的情况)：
A.先接收到 data1，然后接收到 data2。
B.先接收到 data1 的部分数据，然后接收到 data1 余下的部分以及 data2 的全部。
C.先接收到了data1 的全部数据和 data2 的部分数据，然后接收到了 data2 的余下的数据。
D.一次性接收到了data1和data2的全部数据。
对于A这种情况正是我们需要的，在此不再做讨论。
对于B,C,D的情况就是大家经常说的"粘包"，就需要我们把接收到的数据进行拆包，拆成一个个独立的数据包。为了拆包就必须在发送端进行封包。
另外要注意的是：对于UDP来说就不存在拆包的问题。因为UDP是个"数据包"协议，也就是两段数据间是有界限的，在接收端要么接收不到数据要么就是接收一个完整的一段数据，不会少接收也不会多接收。
对于什么是粘包、拆包问题，我想先举两个简单的应用场景：
对于第一种情况，服务端的处理流程可以是这样的：当客户端与服务端的连接建立成功之后，服务端不断读取客户端发送过来的数据，当客户端与服务端连接断开之后，服务端知道已经读完了一条消息，然后进行解码和后续处理...。对于第二种情况，如果按照上面相同的处理逻辑来处理，那就有问题了，我们来看看第二种情况下客户端发送的两条消息递交到服务端有可能出现的情况：
第一种情况：
服务端一共读到两个数据包，第一个包包含客户端发出的第一条消息的完整信息，第二个包包含客户端发出的第二条消息，那这种情况比较好处理，服务器只需要简单的从网络缓冲区去读就好了，第一次读到第一条消息的完整信息，消费完再从网络缓冲区将第二条完整消息读出来消费。
没有发生粘包、拆包示意图
第二种情况：
服务端一共就读到一个数据包，这个数据包包含客户端发出的两条消息的完整信息，这个时候基于之前逻辑实现的服务端就蒙了，因为服务端不知道第一条消息从哪儿结束和第二条消息从哪儿开始，这种情况其实是发生了TCP粘包。
TCP粘包示意图
第三种情况：
服务端一共收到了两个数据包，第一个数据包只包含了第一条消息的一部分，第一条消息的后半部分和第二条消息都在第二个数据包中，或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息，第二个数据包包含了第二条消息的剩下部分，这种情况其实是发送了TCP拆，因为发生了一条消息被拆分在两个包里面发送了，同样上面的服务器逻辑对于这种情况是不好处理的。
TCP拆包示意图
产生tcp粘包和拆包的原因
我们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。
tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。
发生TCP粘包、拆包主要是由于下面一些原因：
"粘包"可发生在发送端也可发生在接收端。
1、由Nagle算法造成的发送端的粘包：
Nagle算法是一种改善网络传输效率的算法。简单的说，当我们提交一段数据给TCP发送时，TCP并不立刻发送此段数据，而是等待一小段时间，看看在等待期间是否还有要发送的数据，若有则会一次把这两段数据发送出去。这是对Nagle算法一个简单的解释，详细的请看相关书籍。像 C 和 D 的情况就有可能是 Nagle 算法造成的。
2、接收端接收不及时造成的接收端粘包：
TCP会把接收到的数据存在自己的缓冲区中，然后通知应用层取数据。当应用层由于某些原因不能及时的把TCP的数据取出来，就会造成TCP缓冲区中存放了几段数据。
如何解决拆包粘包
既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：
答:1）交换机
在计算机网络系统中，交换机是针对共享工作模式的弱点而推出的。交换机拥有一条高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条背 部总线上，当控制电路收到数据包以后，处理端口会查找内存中的地址对照表以确定目的MAC（网卡的硬件地址）的NIC（网卡）挂接在哪个端口上，通过内部 交换矩阵迅速将数据包传送到目的端口。目的MAC若不存在，交换机才广播到所有的端口，接收端口回应后交换机会“学习”新的地址，并把它添加入内部地址表 中。
交换机工作于OSI参考模型的第二层，即数据链路层。交换机内部的CPU会在每个端口成功连接时，通过ARP协议学习它的MAC地址，保存成一张 ARP表。在今后的通讯中，发往该MAC地址的数据包将仅送往其对应的端口，而不是所有的端口。因此，交换机可用于划分数据链路层广播，即冲突域；但它不 能划分网络层广播，即广播域。
交换机被广泛应用于二层网络交换，俗称“二层交换机”。
交换机的种类有：二层交换机、三层交换机、四层交换机、七层交换机分别工作在OSI七层模型中的第二层、第三层、第四层盒第七层，并因此而得名。
2）路由器
路由器（Router）是一种计算机网络设备，提供了路由与转送两种重要机制，可以决定数据包从来源端到目的端所经过 的路由路径（host到host之间的传输路径），这个过程称为路由；将路由器输入端的数据包移送至适当的路由器输出端(在路由器内部进行)，这称为转 送。路由工作在OSI模型的第三层——即网络层，例如网际协议。
路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。 路由器与交换器的差别，路由器是属于OSI第三层的产品，交换器是OSI第二层的产品(这里特指二层交换机)。
3）网关
网关（Gateway），网关顾名思义就是连接两个网络的设备，区别于路由器（由于历史的原因，许多有关TCP/IP 的文献曾经把网络层使用的路由器（Router）称为网关，在今天很多局域网采用都是路由来接入网络，因此现在通常指的网关就是路由器的IP），经常在家 庭中或者小型企业网络中使用，用于连接局域网和Internet。
网关也经常指把一种协议转成另一种协议的设备，比如语音网关。
在传统TCP/IP术语中，网络设备只分成两种，一种为网关（gateway），另一种为主机（host）。网关能在网络间转递数据包，但主机不能 转送数据包。在主机（又称终端系统，end system）中，数据包需经过TCP/IP四层协议处理，但是在网关（又称中介系 统，intermediate system）只需要到达网际层（Internet layer），决定路径之后就可以转送。在当时，网关 （gateway）与路由器（router）还没有区别。
在现代网络术语中，网关（gateway）与路由器（router）的定义不同。网关（gateway）能在不同协议间移动数据，而路由器（router）是在不同网络间移动数据，相当于传统所说的IP网关（IP gateway）。
网关是连接两个网络的设备，对于语音网关来说，他可以连接PSTN网络和以太网，这就相当于VOIP，把不同电话中的模拟信号通过网关而转换成数字信号，而且加入协议再去传输。在到了接收端的时候再通过网关还原成模拟的电话信号，最后才能在电话机上听到。
对于以太网中的网关只能转发三层以上数据包，这一点和路由是一样的。而不同的是网关中并没有路由表，他只能按照预先设定的不同网段来进行转发。网关最重要的一点就是端口映射，子网内用户在外网看来只是外网的IP地址对应着不同的端口，这样看来就会保护子网内的用户。
一、HTML
HTML(HyperTextMark-upLanguage)即超文本标记语言，是WWW的描述语言。
二、XML
XML即ExtentsibleMarkup Language(可扩展标记语言)，是用来定义其它语言的一种元语言，其前身是SGML(标准通用标记语言)。它没有标签集(tagset)，也没有语法规则(grammatical rule)，但 是它有句法规则(syntax rule)。任何XML文档对任何类型的应用以及正确的解析都必须是良构的(well-formed)，即每一个打开的标签都必须有匹配的结束标签，不得含有次序颠倒的标签，并且在语句构成上应符合技术规范的要求。XML文档可以是有效的(valid)，但并非一定要求有效。所谓有效文档是指其符合其文档类型定义(DTD)的文档。如果一个文档符合一个模式(schema)的规定，那么这个文档是模式有效的(schema valid)。
三、HTML与XML的区别
通过以上对HTML及XML的了解，我们来看看他们之间到底存在着什么区别与联系
xml和html都是用于操作数据或数据结构，在结构上大致是相同的，但它们在本质上却存在着明显的区别。综合网上的各种资料总结如下。
（一）、语法要求不同：
1. 在html中不区分大小写，在xml中严格区分。
2. 在HTML中，有时不严格，如果上下文清楚地显示出段落或者列表键在何处结尾，那么你可以省略</p>或者</li>之类的结束标记。在XML中，是严格的树状结构，绝对不能省略掉结束标记。
3. 在XML中，拥有单个标记而没有匹配的结束标记的元素必须用一个/ 字符作为结尾。这样分析器就知道不用查找结束标记了。
4. 在XML中，属性值必须分装在引号中。在HTML中，引号是可用可不用的。
5. 在HTML中，可以拥有不带值的属性名。在XML中，所有的属性都必须带有相应的值。
6. 在XML文档中，空白部分不会被解析器自动删除；但是html是过滤掉空格的。
（二）、标记不同：
1、html使用固有的标记；而xml没有固有的标记。
2、Html标签是预定义的；XML标签是免费的、自定义的、可扩展的。
（三）、作用不同：
1. html是用来显示数据的；xml是用来描述数据、存放数据的，所以可以作为持久化的介质！Html将数据和显示结合在一起，在页面中把这数据显示出来；xml
则将数据和显示分开。 XML被设计用来描述数据，其焦点是数据的内容。HTML被设计用来显示数据，其焦点是数据的外观。
2. xml不是HTML的替代品，xml和html是两种不同用途的语言。 XML 不是要替换 HTML；实际上XML 可以视作对 HTML 的补充。XML 和HTML 的目标不同HTML 的设计目标是显示数据并集中于数据外观，而XML的设计目标是描述数据并集中于数据的内容。
3. 没有任何行为的XML。与HTML 相似，XML 不进行任何操作。（共同点）
4. 对于XML最好的形容可能是: XML是一种跨平台的，与软、硬件无关的，处理与传输信息的工具。
5. XML未来将会无所不在。XML将成为最普遍的数据处理和数据传输的工具。
HTML(Hypertext Markup Language，超文本标记语言), 用来向浏览器说明内容的结构。
核心功能：标记内容，为内容添加语义结构（层次，关系和含义。不需要考虑外观，这是CSS的工作）。
作为网页内容的载体，HTML包含了用户需要浏览的内容，包括图文、视频，即构成网页的基本元素。HTML是网页的结构（Structure），需要有多种框架和布局，比如frameset框架集、iframe内联框架、div+css布局、table布局等，同时支持表单提交（HTML Form），包括基础表单、input输入框、输入框类型、文本域、列表、label等。当前，大家通用的是HTML5，其中还有一些新增元素，比如footer、header等。
DOM(Document Object Model, 文档对象模型)指的是HTML标签的层次结构。每一对HTML标签（有的时候是一个标签）都是一个元素。这些元素，我们一般用拟人化的方法来称呼它们，比如: 父元素，子元素，同胞元素，祖先元素，后代元素。浏览器同构解析DOM来操作页面内容。
CSS(Cascading Style Sheets, 层叠样式表)，控制DOM元素的视觉外观。
CSS的作用是效果，或者说是表现（Presentation），比如网页上的动态文字、文字的色彩、字体、动画效果。正是因为CSS的存在使得HTML变得丰富多样。学习CSS，可以从版本CSS3开始，要了解CSS3的动画效果，如2D变换、过渡、特殊图形的绘制，雪碧图、滑动门等等都是常见的效果；除此之外，CSS3还有媒体查询（Media Queries）、grid，以及多列布局、用户界面等。CSS部分需要配合HTML，并结合实例来加以学习，这样效果会跟好。
如果说一个网页只有“结构”和“表现”，而缺少了用户与网页的交互，即行为（Behavior），那么这样的网页就如一潭死水，无法形成良好的用户体验。好的用户体验不仅可以让用户鼠标放在哪里、哪里就会产生人性化的效果，而且可以增强用户的可操作性，例如购物网站用户的订购，网页会实时显示用户的购物动态。这样一来，JavaScript就有了编程的意味。和其他编程语言一样，JavaScript也有数据类型、条件语句、分支语句、字符串详解、数组详解、对象、函数、数值、Math函数、作用域。如果这一部分可以学会，便可以往更深的内容去发展。
标签：从服务器 nts rest api ftp 硬件 很多 ESS range 网络流
原文地址：https://www.cnblogs.com/xidianzzh/p/13339163.html
