本文对面试/笔试过程中经常会被问到的一些关于计算机网络的问题以及一些基础知识进行了梳理和总结，一方面方便自己查看学习，另一方面也希望为找工作的同学们提供一个复习参考。
其它面试知识点突击整理：
| 序号 | 文章 |
|---|---|
| 1 | Java基础面试突击 |
| 2 | JVM面试突击 |
| 3 | 设计模式面试突击 |
| 4 | 并发编程面试突击 |
| 5 | 消息队列Kafka面试突击 |
| 6 | Redis面试突击 |
| 7 | 计算机网络面试突击 |
| 8 | Spring面试突击 |
| 9 | Dubbo面试突击 |
| 10 | MyBatis面试突击 |
| 11 | 操作系统面试突击 |
| 12 | MySQL面试突击 |
| 13 | Linux命令面试突击 |
文章目录
一、计算机网络模型
TCP/IP 与 OSI 都是为了使网络中的两台计算机能够互相连接并实现通信与回应，但他们最大的不同在于，OSI 是一个理论上的网络通信模型，而 TCP/IP 则是实际上的网络通信标准。
1. OSI七层模型
1、物理层：实现计算机节点之间比特流的透明传输，规定传输媒体接口的标准，屏蔽掉具体传输介质和物理设备的差异，使数据链路层不必关心网络的具体传输介质，按照物理层规定的标准传输数据就行
2、数据链路层：通过差错控制、流量控制等方法，使有差错的物理线路变为无差错的数据链路。
数据链路层的几个基本方法：数据封装成桢、透明传输、差错控制、流量控制。
- 封装成桢：把网络层数据报加头和尾，封装成帧，帧头中包括源MAC地址和目的MAC地址。
- 透明传输：零比特填充、转义字符。
- 差错控制：接收者检测错误,如果发现差错，丢弃该帧，差错控制方法有 CRC 循环冗余码
- 流量控制：控制发送的传输速度，使得接收方来得及接收。传输层TCP也有流量控制功能，但TCP是端到端的流量控制，链路层是点到点（比如一个路由器到下一个路由器）
3、网络层：实现网络地址与物理地址的转换，并通过路由选择算法为分组通过通信子网选择最适当的路径
- 网络层最重要的一个功能就是：路由选择。路由一般包括路由表和路由算法两个方面。每个路由器都必须建立和维护自身的路由表，一种是静态维护，也就是人工设置，适用于小型网络；另一种就是动态维护，是在运行过程中根据网络情况自动地动态维护路由表。
4、传输层：提供源端与目的端之间提供可靠的透明数据传输，传输层协议为不同主机上运行的进程提供逻辑通信。
- 网络层协议负责的是提供主机间的逻辑通信；
- 传输层协议负责的是提供进程间的逻辑通信。
5、会话层：是用户应用程序和网络之间的接口，负责在网络中的两节点之间建立、维持、终止通信。
6、表示层：处理用户数据的表示问题，如数据的编码、格式转换、加密和解密、压缩和解压缩。
7、应用层：为用户的应用进程提供网络通信服务，完成和实现用户请求的各种服务。
2. TCP/IP模型
TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议。TCP/IP协议族按照层次由上到下，层层包装。
上图表示了TCP/IP协议中每个层的作用，而TCP/IP协议通信的过程其实就对应着数据入栈与出栈的过程。入栈的过程，数据发送方每层不断地封装首部与尾部，添加一些传输的信息，确保能传输到目的地。出栈的过程，数据接收方每层不断地拆除首部与尾部，得到最终传输的数据。
二、网络篇
1. 公钥和私钥
公钥和私钥是通过一种算法得到的一个密钥对，公钥是秘钥对中公开的部分，私钥是非公开的部分。如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。
原则：公钥公开，私钥只有自己拥有。
2. 对称加密与非对称加密
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
总结一下：通过非对称加密的方式把秘钥发送过去，接下来用这个秘钥一直进行对称加密。即：第一次通信采用非对称加密，接下来的通信采用对称加密。
3. HTTP与HTTPS的相关问题
3.1 HTTP概念
HTTP协议：超文本传输协议。是应用层协议，是基于TCP协议的，明文传输，客户端与服务器端都无法验证对方的身份；
超文本：广义上的文本，包括图片、视频、压缩包、超链接等。
3.2 HTTP的特点
-
简单、灵活：HTTP头部的各类字段组成都没有固定要求，允许开发人员自定义和补充。
-
无状态：服务器不会记录HTTP的状态，减轻了服务器的开销。 但是在完成关联性操作时不方便（如玩4399小游戏，不能换一个游戏就重新登一次账户）
解决办法：使用Cookie技术，通过在请求和响应报文中写入Cookie信息来来控制客户端的状态。
当客户端第一次请求后，服务器会下发一个装有客户信息的Cookie，后续客户端请求服务器时，带上Cookie，服务器就能识别出是谁。
-
不安全
- HTTP传输文本时采用明文传输，不加密，可以直接看见信息。
- 通信时不会验证双方身份，可能访问虚假用户
- 传输过程中的报文可能遭到无疑篡改。
3.3 HTTP的状态码
3.4 HTTPS概念
HTTPS协议是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。
3.5 HTTPS为什么安全？
-
混合加密
作用：防窃听
混合加密：即同时采用公钥和私钥加密，更安全，更高效，更不易被破解。 具体操作方法见问本文章的第一个问题。
- HTTPS采用对称加密和非对称加密结合的混合加密方式
- 在通信建立前采用非对称加密的方式交换秘钥，后续就不在使用非对称加密
- 在通信过程中全部使用对称加密的会话秘钥方式，加密明文数据。
-
摘要算法
作用：防止数据被篡改。
摘要算法：实现数据完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了被篡改的风险。
过程
-
客户端发送明文前，会通过摘要算法算出明文的指纹，发送时明文和指纹一同加密，发送给服务器。
-
服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前指纹做比较，若相同，则说明数据是完整的。
-
-
数字证书
作用：解决身份认证问题。
过程：借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构办法）中，只要证书是可信的，公钥就是可信的。
-
采用HTTPS加密的具体流程
假设电脑A要向电脑B发送数据
电脑A发送数据前，先通过摘要算法计算出明文的指纹，然后将明文+指纹打包成数据包，并将自己的对称加密的秘钥放入数据报， 同时向电脑B索要公钥。
电脑B将公钥发送过来后，电脑A采用非对称加密的方式，通过电脑B的公钥将自己的数据包加密（非对称加密的原理见之前的解答），加密后，发送给电脑B
电脑B收到电脑A发送过来的数据包后，发现是非对称加密的方式，于是使用自己的私钥解密， 解密后通过计算该数据包的指纹， 与数据包内指纹对比， 若指纹相同，则表示数据没有丢失。
接下来的通信，双方都将使用数据包内的秘钥以对称加密的方式通信。
3.6 HTTP与HTTPS区别
端口不同：HTTP与HTTPS使用不同的连接方式，用的端口也不一样，前者是80，后者是443；资源消耗：和HTTP通信相比，HTTPS通信会由于加减密处理消耗更多的CPU和内存资源；开销：HTTPS通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
4. 客户端在使用HTTPS方式与Web服务器通信时的步骤
- 客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
- Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
- 客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。
- 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
- Web服务器利用自己的私钥解密出会话密钥。
- Web服务器利用会话密钥加密与客户端之间的通信。
5. 从输入URL到页面加载发生了什么
大致流程
- DNS请求
- HTTPs加密
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
- DNS解析（核心：递归、映射）
具体叙述
-
DNS概述
如果说ARP协议是用来将IP地址转换为MAC地址，则DNS协议就是将域名转换为IP地址。（IP地址面向主机，域名面向用户）。
DNS(Domain Name System，域名系统)，因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。域名服务器是层级结构，依次分为
根域名、顶级域名、权限域名、本地域名服务器 -
域名解析过程
1 输入域名后，先查找自己主机对应的域名服务器，域名服务器先查找自己数据库中的数据
2 若没有，就向上级域名服务器进行查找，以此类推
3 最多回溯到根域名服务器
4 DNS缓存：域名服务器自身也会进行缓存，把曾经访问过的域名和IP缓存，加速查找
5 DNS负载均衡：DNS返回的IP地址并非每次都一样，DNS可以根据每台机器的负载量、该机器离用户地理位置的距离等返回一个合适机器的IP给用户。
-
HTTPs加密
见上一个回答
-
建立TCP连接
同上
-
HTTP请求
1 http为80，https为443.
2 请求报文：请求报文头、请求行、请求正文
3 常用方法：get、post
-
服务器进行HTTP响应
响应报文头、状态码、响应报文
-
浏览器解析渲染页面
1 接收到响应报文后，解析HTML、css、js等文件进行解析渲染首部
2 先解析HTML文件构建dom树，接下来解析CSS文件构建渲染树，使用JS引擎对JS进行解析
-
Web优化：对内容压缩、对一些内容缓存等。
或：从输入网址到获得页面的过程
- 浏览器查询DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
- 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
- TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
- 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
- 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
- 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
6. TCP协议的六种标志
SYN：同步标志
置1表示请求进入同步状态，二者同步即可通信。
ACK：确认标志
置1表示确认号合法，为0表示数据段不包含确认信息，确认号被忽略。
RST：复位标志
用于复位某种原因引起出现的错误连接
URG：紧急标志
紧急指针，置1时，用来避免TCP数据流中断。
PSH：推送标志
置1时，请求的数据段在接收方得到后直接送到应用程序，不必等待缓冲区满再传送
FIN：完成标志
置1时，表示此为完成报文，用来释放连接，表示发送方已经没有数据发送了
7. IP地址分类
ABCDE五类，ABC为基本类，DE作为多播和保留使用，为特殊地址。
A类地址：以0开头
B类地址：以10开头
C类地址：以110开头
D类地址：以1110开头
E类地址：以1111开头，保留地址
8. 常见状态码
-
请求已被接受，正在处理
-
请求被成功处理 200ok
-
重定向，要完成请求必须进一步处理（301 永久性转移，302：暂时性转移，304：已缓存） -
客户端错误，请求不合法（400，请求有语法问题；403:拒绝请求；404:客户端所访问的页面不存在） -
服务器错误（500:服务器内部错误；504:服务器不可用）
9. 三次握手与四次挥手
请参考：TCP的三次握手与四次挥手理解
包括：
-
三次握手与四次挥手
-
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
-
为什么不能用两次握手进行连接？
-
如果已经建立了连接，但是客户端突然出现故障了怎么办？
-
三次握手过程中可以携带数据吗
第三次握手时可以携带数据，但是第一、二次不行。
原因：设想这样的场景：若第一次握手可以携带数据，有人要恶意攻击服务器，则他每次都可以在第一次握手中的SYN报文中放入大量数据，会让服务器花费很多时间、空间来处理报文。
也就是说：第一次握手无法放数据，保证了服务器的安全性。而第三次握手时，已经代表成功的建立了连接，从客户端携带数据到服务器也是被理解的。
-
SYN攻击是什么
概念：Client在短时间伪造大量不存在的ip地址，向Server不断发送SYN包，Server则回复确认包，并等待Client确认，这些包将长时间占用未连接队列，导致正常的SYN请求因为队列满被丢弃，从而引起网络拥塞甚至系统瘫痪（Dos/DDoS攻击）
如何检测：当看到大量半连接状态，且源地址IP为随机时，即可断定为一次SYN攻击（Linux中的netstat命令）。
解决办法：缩短SYN时间，过滤网关防护等。
10. 客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？
服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认
1)、DDos 攻击
- 客户端向服务端发送请求链接数据包
- 服务端向客户端发送确认数据包
- 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认
2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )
- 限制同时打开SYN半链接的数目
- 缩短SYN半链接的Time out 时间
- 关闭不必要的服务
三、TCP、UDP篇
1. 网络中各层协议
1.1 应用层
典型设备：应用程序
协议
FTP：文件传输协议<21>，减少或消除不同操作系统下处理文件的不兼容性SSH/TLS：安全外壳协议SMTP/POP3：用于发送/接收邮件HTTP：超文本传输协议<80>，面向事务的应用层协议
1.2 传输层
典型设备：进程和端口
数据单元：数据段
协议
TCP：面向连接、可靠、有序、无丢失、不重复UDP：最大努力交付
1.3 网络层
典型设备：路由器、防火墙、多层交换机
数据单元：数据包
协议
IP：网络之间互连的协议ARP：地址解析协议，实现通过IP地址得知其物理地址ICMP：Internet控制报文协议，在IP主机、路由器之间传递控制消息RIP：路由信息协议BGP：边界网关协议
1.4 数据链路层
典型设备：网卡、网桥、交换机
数据单元：帧
协议
- ARQ：自动重传请求协议，错误纠正协议（停止等待ARQ协议和连续ARQ协议）
- 停止等待协议：CSMA/CD：总线型网络，载波监听、碰撞检测
- PPP：点对点协议
校验方法：循环冗余校验CRC
1.5 物理层
典型设备：中继器、集线器、网线等
数据单元：比特bit
2. TCP与UDP
2.1 TCP首部
源端口号/目标端口号：表示数据从哪个进程来，到哪个进程去。
32位序号：由于TCP面向字节流，将大文件拆分成多个字节传输，序号的作用是为字节排序。
确认序号：告诉对方，要从第几个字节开始发数据，起到确认收到的作用。
首部长度：表示首部长度
保留位：无作用
6个标志：URG、ACK、PSH、SYN、FIN
窗口：告诉对方本人的接收窗口有多大，你的发送窗口不得大于我的接收窗口，否则会出现大量的包被丢弃
校验和：对信息进行验证，防止信息在传送过程中丢失
紧急指针：紧急发送数据的方式
2.2 UDP首部
2.3 特点与区别
-
TCP面向连接：传递数据前，有三次握手建立连接，传递数据时，有确认、窗口、重传和拥塞控制机制，数据传完后，还会通过四次握手断开连接，可靠 -
UDP无连接：知道对端的IP和端口号就可以发送，尽最大努力交付，无需建立连接，不可靠 -
TCP面向字节流：把数据看成一连串无结构的字节流 -
UDP面向报文：没有拥塞控制 -
TCP的通信：点对点 -
UDP通信：支持一对一、一对多、多对一、多对多通信 -
TCP首部开销
20字节 -
UDP首部开销
8字节。
2.4 TCP如何保证传输数据的可靠性
-
对失序数据包重排序（序号字段）：由于TCP面向字节流，因此当TCP报文段到达时，会根据序号字段对数据重排序
-
数据包校验（校验字段）：若数据在传输过程中出错or丢失，则直接丢弃，启动超时重传；若发送了重复数据，则丢弃重复数据
-
超时重传：当TCP发送一个段后，会启动一个定时器，等待目的端确认收到这个报文段，若不能及时收到一个确认，将重发这个报文段
-
流量控制：TCP连接的每一方都有固定大小的缓存空间，TCP接收端只允许另一端发送接收端缓冲区所能接纳的数据，可以防止较快主机使较慢主机的缓冲区溢出。流量控制协议是：滑动窗口协议
-
拥塞处理
2.5 TCP的拥塞处理
拥塞窗口cwnd：其值取决于网络的拥塞程度，且动态变化。
维护原则：只要网络没有出现拥塞，就增大一些，出现了，就减小一些。
判断是否出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生重传）
慢开始门限ssthresh
-
cwnd < ssthresh：使用慢开始算法 -
cwnd > ssthresh：使用拥塞避免算法 -
cwnd = ssthresh：既可以使用慢开始算法，也可使用拥塞避免算法
拥塞处理概念
若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能会变坏，这种情况叫拥塞。
拥塞控制就是：防止过多的数据注入网络，可以使网络中的路由器或链路不至过载。
拥塞控制的方法主要有以下四种：
-
慢开始：
每个传输轮次，拥塞窗口cwnd能传输的报文段都扩大一倍。当cwnd等于慢开始门限后，改用拥塞避免算法。 -
拥塞避免：让拥塞窗口缓慢增长，传输轮次，cwnd能传输的报文段数量+1。
若发生重传，则
cwnd置1，ssthresh减半，并重新开始慢开始算法。
-
快重传：使发送方尽快进行重传。报文段都是按顺序传送的，若收到了失序的报文段，要发出对已收到报文段的重复确认。
发送方一旦受到三个连续的重复确认，就将相应的报文段立即上传。而不是等报文段的超时重传计时器超时在重传。并直接执行快恢复算法。
-
快恢复：
将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半，开始执行拥塞避免算法。
2.6 TCP粘包和拆包
-
什么是TCP粘包？
TCP粘包是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓存区来看，后一包的数据头紧接着前一包的数据尾，出现粘包的原因是多方面的，可能来自发送方，也可能来自接收方。
-
TCP粘包原因
1）、发送方原因：
要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
TCP默认使用Nagle算法，Nagle算法可能造出现粘包问题。Nagle算法主要作用：
减少网络中报文段的数量。而Nagle算法主要做两件事：- 只有上一个分组得到确认，才会发送下一个分组
- 收集多个小分组，在一个确认到来时一起发送
2）、接收方原因
接收数据端的应用层没有及时读取接收缓存区中的数据，将发生粘包。
-
什么时候需要处理粘包现象
若粘包的多组数据为同一块数据(文件)的不同部分，则无需处理。
若多个分组毫无关联，则需要处理粘包现象。 -
如何处理粘包现象？
1）、发送方
可以通过关闭Nagle算法解决，使用
TCP_NODELAY选项来关闭算法2）、接收方
接收方没有办法处理粘包显现，只能交给应用层处理
3）、应用层
应用层解决粘包的方法非常简单，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。
解决方法：循环处理，应用程序从接受缓存中读取分组时，读完一条数据，就应循环读取下一条数据，直到所有数据都被处理完成，但如何判断每条数据的长度呢？
- 格式化数据：每条数据都有固定格式，如开始符，结束符等。
- 这种方法简单可行，但选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
- 发送长度：发送每条数据时，数据包中有专门的位置记录该数据的长度，当应用层读取数据包时，就可以根据数据包长度将每个分组进行拆包。
应用层处理粘包的方法叫拆包。
-
UDP会不会产生粘包问题？
TCP：为了保证可靠传输并减少额外开销，采用了基于流的传输，流传输不会把消息按个传输，而是无保护消息边界的。保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息。UDP：面向消息传输，有保护消息边界，接收方一次只接受一条独立的消息，因此不存在粘包问题。
2.7 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服务。
2.8 get与post区别
- get在浏览器回退时是无害的，因为其会被浏览器主动cache，而post会再次提交请求。
get请求只能进行url编码，在url中传送的参数有长度限制，并且参数直接暴露在url上，不安全。而post没有，post放在request body中。- 对参数的数据类型，
get只接受ascll字符，而post没有限制。
底层原理
由于Http的底层是TCP/IP、所以get/post的底层也是TCP数据包，不同的是，对于get，浏览器会把http header和data一并发送出去，服务器响应200；而对于post，浏览器先发送header，服务器响应100 continue，浏览器在发送data，服务器响应200 ok（返回数据）
GET请求如何进行URL编码
将数据解析成ASCII码表示，服务器端在接收到数据时，就可以遍历字节流。通过&，=等关键信息来确定数据之间的分割。
如果字符串本身就带有&，=这些关键字呢？
解决办法：在其前面加上%，这样服务端会把紧跟在%后的字节当成普通字节。
2.9 网络层的ARP协议工作原理
网络层的ARP协议完成了IP地址与物理地址的映射。
-
首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
-
当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
-
网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；
-
源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
四、缓存篇
session、cookie与Application
Session机制采用的是服务器保持状态的方案
Cookie机制采用的是客户端保持状态的方案
1. cookie及其API
Cookie实际上是一小段文本信息，客户端请求服务器，若服务器需要记录用户状态，就是用response向客户端颁发一个cookie。
当浏览器再次请求该网站时，浏览器会把请求的网址连通该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。
2. Session及其API
客户端请求服务器，若用服务器记录该用户状态，就获取session来保存状态。
这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用
若客户端请求不包含sessionid，则为此客户端创建一个session并生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。
保存sessionid的方式可以采用cookie机制。
3. Session与Cookie比较
实现机制：Session的实现常常依赖于Cookie。通过Cookie机制回传SessionID。
大小限制：Cookie有大小限制，并且浏览器对每个站点也有个数限制，session无大小限制，理论上只与服务器的内存大小有关。
安全性：Cookie存在安全隐患，通过拦截或本地文件找到cookie后可以进行攻击，而session由于保存在服务器端，相对更安全。
服务器资源消耗：Session保存在服务器端过一段时间才会消失，若session过多会增加服务器压力。
4. Application
即JavaWeb中的ServletContext：与一个Web应用程序相对于，为应用程序提供了一个全局状态，所有客户都可以使用该状态。
五、攻击篇
1. XSS攻击
指恶意攻击者利用网站没有对用户提交的数据进行转义处理or过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去。
使别的用户访问都会执行响应的嵌入代码，进而盗取资料、利用用户身份侵害等。如非法转账、强制发送邮件等。
主要原因：过于信任客户端提交的数据
解决办法：只要是客户端提交的数据，都应进行相应的过滤处理才能进行下一步操作。如将重要的信息设置为Http only等
参考：
9823
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
