计算机网络（秋招准备，自用）
计算机网络秋招知识储备
- 一、OSI七层模型、TCP/IP四层模型、五层模型、各层常用协议、重要设备（工作于第几层）
-
- 1.各种模型以及各层的功能作用
-
- 1.物理层
- 2.数据链路层
- 3.网络层
- 4.传输层
- 5.会话层
- 6.表示层
- 5.应用层
- 2.常用设备及其工作的层次
- 3.常用协议及其所属的层次
-
- 1.数据链路层
-
- ARP（Address Resolution Protocol）地址解析协议，根据IP地址获取物理地址。
- MTU
- 2.网络层
-
- ICMP
- IP IP协议是TCP/IP协议族的核心协议，为上层协议提供无状态、无连接、不可靠的服务
- RIP动态路由选择协议（网络层协议）
- OSPF协议
- 3.传输层 TCP、UDP单独列出
- 4.应用层
- 二、TCP UDP相关
-
- TCP三次握手、四次挥手
-
- 三次握手，以及accept（）函数
- 四次挥手以及time_wait、close_wait状态
- TCP粘包、拆包的问题
- TCP keep_alive状态
- TCP保证可靠的机制
- TCP拥塞控制、流量控制
- UDP如何实现可靠
- 三、HTTP相关
-
- 1.HTTP与TCP的区别与联系
- HTTP 状态码及发展
- HTTP与HTTPS的区别
- HTTPS安全连接
- 请求报文、响应报文
- Get Post的区别
- cookie、session、token的区别以及session的负载均衡相关问题
-
- session负载均衡
- 经典url问题
- DNS域名解析
- 四、socket相关
- 五、网络安全相关
-
- SQL注入攻击
- XSS攻击（跨站点脚本攻击，攻击客户端）
- CSRF攻击（跨站点请求伪造，攻击服务端）
- 文件上传漏洞
- DDOS攻击
一、OSI七层模型、TCP/IP四层模型、五层模型、各层常用协议、重要设备（工作于第几层）
1.各种模型以及各层的功能作用
参考：计算机网络OSI七层模型及其功能
五层模型即将TCP/IP四层模型的网际接口层拆分成数据链路层和物理层
通过层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯，帮助不同类型的主机实现数据传输 。
1.物理层
利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。
2.数据链路层
通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。数据链路层的具体工作是接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层；并且，还负责处理接收端发回的确认帧的信息，以便提供可靠的数据传输。
在计算机网络中由于各种干扰的存在，物理链路是不可靠的。因此，这一层的主要功能是在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。
该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层。
MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制；
LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。
3.网络层
数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。
一般地，数据链路层是解决同一网络内节点之间的通信，而网络层主要解决不同子网间的通信。
寻址：涉及到mac地址和ip地址的转换
交换：规定不同的信息交换方式。常见的交换技术有：线路交换技术和存储转发技术，后者又包括报文交换技术和分组交换技术。（数据交换方式）
路由算法：当源节点和目的节点之间存在多条路径时，根据路由算法，通过网络为数据分组选择最佳路径，并将信息从最合适的路径由发送端传送到接收端。
连接服务：与数据链路层流量控制不同的是，前者控制的是网络相邻节点间的流量，后者控制的是从源节点到目的节点间的流量。其目的在于防止阻塞，并进行差错检测。
4.传输层
传输层的主要任务就是负责两台主机进程之间的通信提供通用的数据传输服务。（向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。传输层的作用是向高层屏蔽下层数据通信的细节，即向用户透明地传送报文）
在源端和目的端之间提供可靠的透明数据传输，使上层服务用户不必关心通信子网的实现细节。
传输层协议为不同主机上的进程提供逻辑通信，而网络层协议为不同主机提供逻辑通信。
5.会话层
主要任务是：向两个实体的表示层提供建立和使用连接的方法。将不同实体之间的表示层的连接称为会话。因此会话层的任务就是组织和协调两个会话进程之间的通信，并对数据交换进行管理。
用户可以按照半双工、单工和全双工的方式建立会话。当建立会话时，用户必须提供他们想要连接的远程地址。而这些地址与MAC（介质访问控制子层）地址或网络层的逻辑地址不同，它们是为用户专门设计的，更便于用户记忆。域名（DN）就是一种网络上使用的远程地址
6.表示层
它对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层。其主要功能是“处理用户信息的表示问题，如编码、数据格式转换和加密解密”等。
5.应用层
通过应用进程间的交互来完成特定网络应用。应用层交互的数据单元成为报文。
应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。
在互联网中，应用层协议有很多，如域名系统DNS，，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。
2.常用设备及其工作的层次
参考：交换机和路由器的区别、集线器和路由器在功能上的不同
物理层：网卡，网线，集线器，中继器，调制解调器
集线器是物理层设备,采用广播的形式来传输信息。
集线器
网卡
网线：网线是连接计算机与计算机、计算机与其它网络设备的连接线。
数据链路层：网桥，交换机
交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机)，能够进行地址学习，采用存储转发的形式来交换报文。
交换机内有一张MAC表，里面存放着和它相连的所有设备的MAC地址，它会根据收到的数据帧的首部信息内的目的MAC地址在自己的表中查找，如果有就转发，如果没有就放弃。
网络层：路由器
路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。选择通畅快捷的近路，能大大提高通信速度，减轻网络系统通信负荷，节约网络系统资源，提高网络系统畅通率。
路由器内有一份路由表，里面有它的寻址信息（就像是一张地图），它收到网络层的数据报后，会根据路由表和选路算法将数据报转发到下一站（可能是路由器、交换机、目的主机）
网关工作在第四层传输层及其以上
** 为什么有IP和MAC两种地址** ：IP地址决定了网络中数据包如何通过路由器的转发到达目的地，而MAC地址则唯一标识了接受这个数据包的主机。
MAC地址又称为物理地址，每一台主机有一个固定的MAC地址，可以理解成这台主机出厂就具备了该物理地址，就好比人的身份证号，每个人都有自己唯一的身份证号。
IP地址并不是主机唯一的，我们知道IP地址有共有IP地址和私有IP地址之分（如下图所示）。其中公有地址是由统一管理分配的，例如我们搭建了一个网站，希望能被所有地方的人访问到，则需要去购买一个公有的IP地址；私有IP地址则是在局域网内部，比如教研室、宿舍、办公室等大家的IP地址（可通过接入设备，以一个共同的公网IP而连接外网）
3.常用协议及其所属的层次
1.数据链路层
ARP（Address Resolution Protocol）地址解析协议，根据IP地址获取物理地址。
1.发送ARP请求的以太网数据帧 广播 到以太网上的每个主机，ARP请求帧中包含了目的主机的IP地址。
2.目的主机收到了该ARP请求之后，会发送一个ARP应答，里面包含了目的主机的MAC地址。
RARP反向地址转换协议
RARP使只知道自己硬件地址的主机能够知道其IP地址。RARP发出要反向解释的物理地址并希望返回其IP地址，应答包括能够提供所需信息的RARP服务器发出的IP地址。
ARP、RARP
MTU
2.网络层
ICMP
IP协议是一种面向无连接的数据报协议，它是一种不可靠的协议，它不提供任何差错检验。因此网际报文控制协议（Internet Control Message Protocol）ICMP出现了，ICMP协议用于IP主机、路由器之间传递控制消息，这里的控制消息可以包括很多种：数据报错误信息、网络状况信息、主机状况信息等，虽然这些控制消息虽然并不传输用户数据，但对于用户数据报的有效递交起着重要作用
ICMP协议详解
IP IP协议是TCP/IP协议族的核心协议，为上层协议提供无状态、无连接、不可靠的服务
IP协议详解
RIP动态路由选择协议（网络层协议）
RIP是一种基于距离矢量（Distance-Vector）算法的协议，它使用跳数（Hop Count）作为度量来衡量到达目的网络的路由距离。RIP通过UDP报文进行路由信息的交换，使用的端口号为520。
OSPF协议
OSPF组播的方式在所有开启OSPF的接口发送Hello包，用来确定是否有OSPF邻居，若发现了，则建立OSPF邻居关系，形成邻居表，之后互相发送LSA（链路状态通告）相互通告路由，形成LSDB（链路状态数据库）。再通过SPF算法，计算最佳路径（cost最小）后放入路由表。
RIP、OSPF协议的异同
3.传输层 TCP、UDP单独列出
4.应用层
HTTP单独列出
DNS单独列出
常见应用层协议
二、TCP UDP相关
TCP三次握手、四次挥手
三次握手，以及accept（）函数
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据（连接建立,** 调用accept()函数获取连接**）
三次握手的原因：三次握手可以防止已经失效的连接请求报文突然又传输到服务器端导致的服务器资源浪费。例如，客户端先发送了一个SYN，但是由于网络阻塞，该SYN数据包在某个节点长期滞留。然后客户端又重传SYN数据包并正确建立TCP连接，然后传输完数据后关闭该连接。该连接释放后失效的SYN数据包才到达服务器端。在二次握手的前提下，服务器端会认为这是客户端发起的又一次请求，然后发送SYN ，并且在服务器端创建socket套接字，一直等待客户端发送数据。但是由于客户端并没有发起新的请求，所以会丢弃服务端的SYN 。此时服务器会一直等待客户端发送数据从而造成资源浪费。
**accept（）函数 ** accept过程发生在三次握手之后，三次握手完成后，客户端和服务器就建立了tcp连接并可以进行数据交互了。这时可以调用accept函数获得此连接。
accept函数详解
四次挥手以及time_wait、close_wait状态
客户端先发送FIN，进入FIN_WAIT1状态，用来关闭Client到Server的数据传送
服务端收到FIN，发送ACK，进入CLOSE_WAIT状态，客户端收到这个ACK，进入FIN_WAIT2状态
服务端发送FIN，进入LAST_ACK状态，用来关闭Server到Client的数据传送
客户端收到FIN，发送ACK，进入TIME_WAIT状态，服务端收到ACK，进入CLOSE状态（等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。）
四次挥手的原因：由于连接的关闭控制权在应用层，所以被动关闭的一方在接收到FIN包时，TCP协议栈会直接发送一个ACK确认包，优先关闭一端的通信。然后通知应用层，由应用层决定什么时候发送FIN包。应用层可以使用系统调用函数read==0来判断对端是否关闭连接。
TIME_WAIT 是主动关闭链接时形成的，等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长，因此server端应尽量减少主动关闭连接
CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0。
TCP粘包、拆包的问题
TCP是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
产生粘包问题的原因有以下几个：
第一 。应用层调用write方法，将应用层的缓冲区中的数据拷贝到套接字的发送缓冲区。而发送缓冲区有一个SO_SNDBUF的限制，如果应用层的缓冲区数据大小大于套接字发送缓冲区的大小，则数据需要进行多次的发送。
第二种情况是，TCP所传输的报文段有MSS的限制，如果套接字缓冲区的大小大于MSS，也会导致消息的分割发送。
第三种情况由于链路层最大发送单元MTU，在IP层会进行数据的分片。
这些情况都会导致一个完整的应用层数据被分割成多次发送，导致接收对等方不是按完整数据包的方式来接收数据。
粘包问题的最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪。我们通过使用某种方案给出边界，例如：
1.发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
2.包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
3.包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。
4.使用更加复杂的应用层协议。
TCP keep_alive状态
TCP保证可靠的机制
TCP保证可靠性：
（1）序列号、确认应答、超时重传
数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明了它下一次需要接收的数据序列号。如果发送发迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。这个时间一般是2RTT(报文段往返时间）+一个偏差值。
（2）窗口控制与高速重发控制/快速重传（重复确认应答）
TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制，每一个没收到确认应答的数据都要重发。
使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接收1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发；但还有种情况有可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会放过它的，会疯狂向它提醒…
（3）拥塞控制
如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以TCP在为了防止这种情况而进行了拥塞控制。
慢启动：定义拥塞窗口，一开始将该窗口大小设为1，之后每次收到确认应答（经过一个rtt），将拥塞窗口大小2。
拥塞避免：设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加（每次确认应答/每个rtt，拥塞窗口大小+1），以此来避免拥塞。
将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗口大小设为初值1，然后重新进入慢启动过程。
快速重传：在遇到3次重复确认应答（高速重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。
然后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3的大小。
这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的过程，网络不会轻易的发生瘫痪。
TCP拥塞控制、流量控制
TCP的四种拥塞控制算法 1.慢开始 2.拥塞控制 3.快重传 4.快恢复 拥塞控制
流量控制 对发送方发送速率的控制，我们称之为流量控制。流量控制
UDP如何实现可靠
UDP实现可靠传输的参考资料
**QUIC **
QUIC是一种基于 UDP 协议的低时延互联网应用层协议 QUIC协议详解
三、HTTP相关
http与https参考
1.HTTP与TCP的区别与联系
HTTP协议是建立在TCP协议之上的一种应用。
HTTP 状态码及发展
HTTP状态码参考
HTTP的发展 0.9 1.0 1.1 2.0 3.0
HTTP与HTTPS的区别
超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
HTTPS和HTTP的主要区别
1、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTPS安全连接
SSL TLS HTTPS的缺点 涉及的计算环节等参考资料
1.tcp三次握手建立连接（https是建立在Tcp协议上的，因此同样需要三次握手建立连接）
2.客户端发送请求到服务端
3.服务端返回数字证书和公钥（服务器搭建https是会申请一个CA证书，并生成一对私钥和公钥）
4.客户端验证证书的安全性，若验证通过，则生成一个随机数（即对称密钥），利
用公钥对其进行非对称加密，发送到服务端
5.服务端利用私钥进行解密，获得随机数，利用随机数对发送的数据进行对称加
密，发送到客户端
6.客户端利用随机数进行解密，获得数据
7.SSL加密建立，以后都用对称加密进行通信
请求报文、响应报文
请求报文、响应报文参考资料
HTTP请求报文由3部分组成（请求行+请求头+请求体）
请求行：①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL。③是协议名称及版本号。
请求头：是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。与缓存相关的规则信息，均包含在header中
请求体：是报文体，它将一个页面表单中的组件值通过键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数
HTTP的响应报文也由三部分组成（响应行+响应头+响应体）
响应行：①报文协议及版本； ②状态码及状态描述；
响应头：③响应报文头，也是由多个属性组成；
响应体：④响应报文体
Get Post的区别
GET、POST的区别以及一些新增的方法参考资料
GET在浏览器回退时是无害的，无持续性的副作用，如进行搜索；而POST会再次提交请求，有副作用，如数据库内添加新的数据行。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST么有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。一个比较实际的问题是：GET方法可能会产生很长的URL，或许会超过某些浏览器与服务器对URL长度的限制。
cookie、session、token的区别以及session的负载均衡相关问题
cookie session token相关的问题
**session **
当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
cookie cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:“”)、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。
Cookie实际上是一小段的文本信息（key-value格式）。浏览器向服务器发起请求，如果服务器需要记录该状态，服务器就会向浏览器颁发一个Cookie。浏览器会把Cookie保存起来。当浏览器再请求该服务器时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认浏览器状态。
**token ** 是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
cookie和session的区别：
cookie 和session的区别
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗 考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议： 将登陆信息等重要信息存放为SESSION 其他信息如果需要保留，可以放在COOKIE中
session负载均衡
**会话保持 ** Session保持（会话保持）是我们见到最多的名词之一，通过会话保持，负载均衡进行请求分发的时候保证每个客户端固定的访问到后端的同一台应用服务器。会话保持方案在所有的负载均衡都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题。
会话复制 既然，我们的目标是所有服务器上都要保持用户的Session，那么将每个应用服务器中的Session信息复制到其它服务器节点上是不是就可以呢？这就是Session的第二中处理办法：会话复制。
会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：
全局会话复制：利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。
非全局复制：使用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。
会话共享 将session存在一个统一的地方。对于Session来说，肯定是频繁使用的，虽然你可以把它存放在数据库中，但是真正生产环境中我更推荐存放在性能更快的分布式KV数据中
经典url问题
一次完整的HTTP请求过程
域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户。
DNS域名解析
DNS学习参考资料详细
以用户在浏览器输入www.baidu.com为例，我们详细说明一下实际域名查询过程：
- 用户输入www.baidu.com，浏览器调用操作系统resolver发起域名查询，此处不考虑浏览器的域名缓存；resolver封装一个dns请求报文，并将其发给运营商分配的local dns地址（或者用户自己配置的公共dns）；
- local dns查询缓存，如果命中则返回响应结果；否则向根服务器发起查询；
- 根服务器返回com地址。每一层级的DNS服务器都有缓存，实际都是先查缓存，没有缓存才返回下级域，此处不再重复；
- local dns查询com。com返回baidu.com地址；
- local dns查询baidu.com，baidu.com返回www.baidu.com对应记录结果。
四、socket相关
socket相关
网络间的进程是如何通信的？
在本地可以通过进程PID来唯一的标识一个进程，在网络中，TCP/IP本协议族帮我们解决了这个问题。网络层的ip地址可以唯一标识网络中的主机，而传输层的“协议+端口”可以唯一标识主机中的应用程序（进程）。利用三元组（IP地址，协议，端口号）就可以唯一标识网络中的进程，网络中的进程通信就可以利用这个标志与其他进程进行交互。
使用TCP/IP协议的应用程序通常采用应用编程接口：UNIX BSD的套接字（socket）和UNIX System V的TLI（已经被淘汰），来实现网络进程之间的通信。就目前而言，几乎所有的应用程序都是采用socket。
socket
Unix/Linux基本哲学之一“一切皆文件”，都可以用“打开open-读写write/read-关闭close”的模式来操作。
socket是该模式的一种实现，即socket是一种特殊的文件，一些socket函数就是对其进行操作（读/写IO、打开、关闭）。
五、网络安全相关
SQL注入攻击
攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。
用户登录，输入用户名 lianggzone，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
不管用户名和密码是什么内容，使查询出来的用户列表不为空。如何防范SQL注入攻击使用预编译的PrepareStatement是必须的，但是一般我们会从两个方面同时入手。
Web端
1）有效性检验。
2）限制字符串输入的长度。
服务端
1）不用拼接SQL字符串。
2）使用预编译的PrepareStatement。
3）有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)
4）过滤SQL需要的参数中的特殊字符。比如单引号、双引号。
XSS攻击（跨站点脚本攻击，攻击客户端）
跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
如何防范XSS攻击
1）前端，服务端，同时需要字符串输入的长度限制。
2）前端，服务端，同时需要对HTML转义处理。将其中的”<”,”>”等特殊字符进行转义编码。
防 XSS 的核心是必须对输入的数据做过滤处理。
CSRF攻击（跨站点请求伪造，攻击服务端）
跨站点请求伪造，指攻击者通过跨站请求，以合法的用户的身份进行非法操作。可以这么理解CSRF攻击：攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息。
如何防范CSRF攻击
token机制。在HTTP请求中进行token验证，如果请求中没有token或者token内容不正确，则认为CSRF攻击而拒绝该请求。
验证码。通常情况下，验证码能够很好的遏制CSRF攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案。
referer识别。在HTTP Header中有一个字段Referer，它记录了HTTP请求的来源地址。如果Referer是其他网站，就有可能是CSRF攻击，则拒绝该请求。但是，服务器并非都能取到Referer。很多用户出于隐私保护的考虑，限制了Referer的发送。在某些情况下，浏览器也不会发送Referer，例如HTTPS跳转到HTTP。
1）验证请求来源地址；
2）关键操作添加验证码；
3）在请求地址添加 token 并验证。
文件上传漏洞
文件上传漏洞，指的是用户上传一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。
许多第三方框架、服务，都曾经被爆出文件上传漏洞，比如很早之前的Struts2，以及富文本编辑器等等，可被攻击者上传恶意代码，有可能服务端就被人黑了。如何防范文件上传漏洞
文件上传的目录设置为不可执行。
1）判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。
2）对上传的文件类型进行白名单校验，只允许上传可靠类型。
3）上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。
4）限制上传文件的大小。
5）单独设置文件服务器的域名。
DDOS攻击
SYN泛洪攻击和预防
客户端向服务端发送请求链接数据包，服务端向客户端发送确认数据包，客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认
没有彻底根治的办法，除非不使用TCP
DDos 预防：
1）限制同时打开SYN半链接的数目
2）缩短SYN半链接的Time out 时间
3）关闭不必要的服务