面试季-网络安全常见面试题整理1

1、请描述常见 Web 攻击？Owasp TOP10有哪些？

常见 Web 攻击

XSS攻击

XSS（Cross Site Scripting）跨站脚本攻击，为了不与层叠样式表（CSS）混淆，故将跨站脚本攻击缩写为XSS。原理即在网页中嵌入恶意脚本，当用户打开网页时，恶意脚本便开始在用户浏览器上执行，以盗取客户端cookie、用户名、密码，甚至下载木马程式。

解决方法：XSS之所以会发生,是因为用户输入的数据变成了代码。因此,我们需要对用户输入的数据进行HTML转义处理,将其中的“尖括号”、“单引号”、“引号” 之类的特殊字符进行转义编码。

SQL注入攻击

通过把SQL命令伪装成正常的HTTP请求参数,传递到服务端,欺骗服务器最终执行恶意的SQL命令,达到入侵目的。攻击者可以利用SQL注入漏洞,查询非授权信息, 修改数据库服务器的数据,改变表结构,甚至是获取服务器root权限。总而言之,SQL注入漏洞的危害极大,攻击者采用的SQL指令,决定攻击的威力。当前涉及到大批量数据泄露的攻击事件,大部分都是通过利用SQL注入来实施的目的。

如何防范SQL注入攻击

Web端

1）有效性检验。

2）限制字符串输入的长度。

服务端

1）不用拼接SQL字符串。

2）使用预编译的PrepareStatement。

3）有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)

4）过滤SQL需要的参数中的特殊字符。比如单引号、双引号。
 

DDos 攻击

客户端向服务端发送请求链接数据包，服务端向客户端发送确认数据包，客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDos 预防：

1）限制同时打开SYN半链接的数目

2）缩短SYN半链接的Time out 时间

3）关闭不必要的服务

文件上传漏洞

文件上传漏洞，指的是用户上传一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。
许多第三方框架、服务，都曾经被爆出文件上传漏洞，比如很早之前的Struts2，以及富文本编辑器等等，可被攻击者上传恶意代码，有可能服务端就被人黑了。

如何防范文件上传漏洞，文件上传的目录设置为不可执行。

1）判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。

2）对上传的文件类型进行白名单校验，只允许上传可靠类型。

3）上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。

4）限制上传文件的大小。

5）单独设置文件服务器的域名。

CSRF攻击

跨站点请求伪造，指攻击者通过跨站请求，以合法的用户的身份进行非法操作。可以这么理解CSRF攻击：攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息。

如何防范CSRF攻击

安全框架，例如Spring Security。

token机制。在HTTP请求中进行token验证，如果请求中没有token或者token内容不正确，则认为CSRF攻击而拒绝该请求。
验证码。通常情况下，验证码能够很好的遏制CSRF攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案。

referer识别。在HTTP Header中有一个字段Referer，它记录了HTTP请求的来源地址。如果Referer是其他网站，就有可能是

CSRF攻击，则拒绝该请求。但是，服务器并非都能取到Referer。很多用户出于隐私保护的考虑，限制了Referer的发送。在某些情况下，浏览器也不会发送Referer，例如HTTPS跳转到HTTP。

1）验证请求来源地址；

2）关键操作添加验证码；

3）在请求地址添加 token 并验证。

XSS攻击

跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。如何防范XSS攻击

1）前端，服务端，同时需要字符串输入的长度限制。

2）前端，服务端，同时需要对HTML转义处理。将其中的”<”,”>”等特殊字符进行转义编码。

防 XSS 的核心是必须对输入的数据做过滤处理。

Owasp TOP10

（1） 注入

将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

如何防止：

• 防止注入漏洞需要将数据与命令语句、查询语句分隔开来。

• 最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。

• 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。

• 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的JavaEncoder和类似的库提供了这样的转义例程。

• 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录。

（2） 失效的身份认证

通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、**或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

如何防止：

• 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力**和被盗凭据再利用攻击。

• 不要使用发送或部署默认的凭证，特别是管理员用户。

• 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码”列表。

• 修改密码复杂度策略，密码由大/小写字母+特殊字符+数字组成，长度大于8位，定期90天修改密码。

• 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。

• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力**或其他攻击被检测时提醒管理员。

• 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。

（3） 敏感数据泄露

许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者可以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据以及浏览器的交互数据。

如何防止：

• 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。

• 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。

• 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCIDSS标记或拦截。未存储的数据不能被窃取。

• 确保存储的所有敏感数据被加密。

• 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且**管理到位。

• 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被强制执行，如：使用HTTP严格安全传输协议(HSTS)。

• 禁止缓存对包含敏感数据的响应。

• 确保使用密码专用算法存储密码，如：Argon2、scrypt、bcrypt或者PBKDF2。将工作因素(延迟因素)设置在可接受范围。

• 单独验证每个安全配置项的有效性。

（4） XML外部实体(XXE)

当开发人员暴露一个对内部实现对象的引用时，例如，一个文件、目录或者数据库密匙，就会产生一个不安全的直接对象引用。在没有访问控制检测或其他保护时，攻击者会操控这些引用去访问未授权数据。许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

如何防止：

• 尽可能使用简单的数据格式(如：JSON)，避免对敏感数据进行序列化。

• 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。

• 在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。

• 在服务器端实施积极的(“白名单”)输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。

• 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。

• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST工具可以检测源代码中的XXE漏洞。

（5） 失效的访问控制

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

如何防止：

• 除公有资源外，默认情况下拒绝访问。

• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。

• 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。

• 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。

• 禁用Web服务器目录列表，并确保文件元数据(如：git)不存在于Web的根目录中。

• 记录失败的访问控制，并在适当时向管理员告警(如：重复故障)。

• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。

• 当用户注销后，服务器上的JWT令牌应失效。

（6） 安全配置错误

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

如何防止：

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。

• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。

• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分。

• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。

• 向客户端发送安全指令，如：安全标头。

• 在所有环境中能够进行正确安全配置和设置的自动化过程。

（7）跨站脚本(XSS)

当应用程序的新网页中包含不受信任的、未经恰当验证或转义的数据时，或者使用可以创建HTML或JavaScript的浏览器API更新现有的网页时，就会出现XSS缺陷。XSS让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用户重定向到恶意站点。

如何防止：

• 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby3.0或ReactJS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。

• 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文(包括：主体、属性、JavaScript、CSS或URL)对所有不可信的HTTP请求数据进行恰当的转义。

• 在客户端修改浏览器文档时，为了避免DOMXSS攻击，最好的选择是实施上下文敏感数据编码。

• 使用内容安全策略(CSP)是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞(例如：路径遍历覆盖和允许在网络中传输的易受攻击的库)，则该策略是有效的。

（8） 不安全的反序列化

不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，攻击者也可以利用它们来执行攻击，包括：重播攻击、注入攻击和特权升级攻击。

如何防止：

• 执行完整性检查，如：任何序列化对象的数字签名，以防止恶意对象创建或数据篡改。

• 在创建对象之前强制执行严格的类型约束，因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明，所以完全依赖于它是不可取的。

• 如果可能，隔离运行那些在低特权环境中反序列化的代码。

• 记录反序列化的例外情况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引发的例外情况。

• 限制或监视来自于容器或服务器传入和传出的反序列化网络连接。

• 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

（9） 使用含已知漏洞的组件

组件(例如：库、框架和其他软件模块)拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

如何防止：

• 移除不使用的依赖、不需要的功能、组件、文件和文档。

• 利用如versions、DependencyCheck、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。

• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险。

• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。

（10） 不足的日志记录和监控

不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，且通常通过外部检测方检测，而不是通过内部流程或监控检测。

如何防止：

• 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。

• 确保日志以一种能被集中日志管理解决方案使用的形式生成。

• 确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。

• 建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。

2、重要协议分布层

3、请描述arp协议的工作原理

ARP（Address Resolution Protocol），地址解析协议。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查询失败。

4、rip协议是什么？rip的工作原理

RIP ：（Routing Information Protocol，路由信息协议），是内部网关协议IGP（Interior Gateway Protocol），采用距离矢量（也就是用距离作为路由变量）路由算法，使用跳数即（HOP） 来衡量到达目标地址的路由距离，且最大跳数仅为15）

原理：

• 初始化——RIP初始化时，会从每个参与工作的接口上发送请求数据包。该请求数据包会向所有的RIP路由器请求一份完整的路由表。该请求通过LAN上的广播形式发送LAN或者在点到点链路发送到下一跳地址来完成。这是一个特殊的请求，向相邻设备请求完整的路由更新。
• 接收请求——RIP有两种类型的消息，响应和接收消息。请求数据包中的每个路由条目都会被处理，从而为路由建立度量以及路径。RIP采用跳数度量，值为1的意为着一个直连的网络，16，为网络不可达。路由器会把整个路由表作为接收消息的应答返回。
• 接收到响应——路由器接收并处理响应，它会通过对路由表项进行添加，删除或者修改作出更新。
• 常规路由更新和定时——路由器以30秒一次地将整个路由表以应答消息地形式发送到邻居路由器。路由器收到新路由或者现有路由地更新信息时，会设置一个180秒地超时时间。如果180秒没有任何更新信息，路由的跳数设为16。路由器以度量值16宣告该路由，直到刷新计时器从路由表中删除该路由。刷新计时器的时间设为240秒，或者比过期计时器时间多60秒。Cisco还用了第三个计时器，称为抑制计时器。接收到一个度量更高的路由之后的180秒时间就是抑制计时器的时间，在此期间，路由器不会用它接收到的新信息对路由表进行更新，这样能够为网路的收敛提供一段额外的时间。
•  触发路由更新——当某个路由度量发生改变时，路由器只发送与改变有关的路由，并不发送完整的路由表。

5、什么是RARP？工作原理

概括： 反向地址转换协议，网络层协议，RARP与ARP工作方式相反。 RARP使只知道自己硬件地址的主机能够知道其IP地址。RARP发出要反向解释的物理地址并希望返回其IP地址，应答包括能够提供所需信息的RARP服务器发出的IP地址。

原理：

(1)网络上的每台设备都会有一个独一无二的硬件地址，通常是由设备厂商分配的MAC地址。主机从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包，请求RARP服务器回复该主机的IP地址。

(2)RARP服务器收到了RARP请求数据包，为其分配IP地址，并将RARP回应发送给主机。

(3)主机收到RARP回应后，就使用得到的IP地址进行通讯。
 

6、OSPF协议是什么？并描述OSPF的工作原理。

OSPF(Open Shortest Path First开放式最短路径优先)是一个内部网关协议(Interior Gateway Protocol,简称IGP)，用于在单一自治系统(autonomous system,AS)内决策路由。OSPF通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，每个OSPF路由器使用这些最短路径构造路由表。

原理：

首先，当路由器开启OSPF后，路由器之间就会相互发送HELLO报文，HELLO报文中包含一些路由器和链路的相关信息，发送HELLO报文的目的是为了形成邻居表

然后，路由器之间就会发送LSA（LINK STATE ADVERTISEMENT，链路状态通告），LSA告诉自己的邻居路由器和自己相连的链路的状态，最后，形成网络的拓扑表，其实这个过程是很复杂的，他们经过发LSA，记录LSA，装发LSA，最后形成LSDB（链路状态数据库，即拓扑表），

形成拓扑表之后，在经过SPF算法，通过计算LSDB，最后形成路由表。形成路由表后，路由器就可以根据路由表来转发数据包，

但是，这只是理想情况，如果之后，网络拓扑发生了变化，或是网络链路出现了问题，OSPF协议还是会经过这三张表来重新计算新的路由，只不过不会这么复杂了，路由器在默认情况下，10S就会发送一次HELLO报文，以检测链路状态，保证链路始终是正常的。

7、TCP与UDP区别是什么？

原文：https://blog.csdn.net/gao1440156051/article/details/52207032

•  基于连接vs无连接        

他们之间的第一点并且最重要的区别是：TCP是面向连接的协议，而UDP是无连接的协议。这意味着当一个客户端和一个服务器通过TCP发送数据之前，必须先建立连接，他们可以通过TCP发送数据。建立连接的过程也被称为TCP握手，他通过控制消息在客户端和服务器之间互换来实现。下面的图形象描述了TCP握手过程。客户端，它也是TCP连接的发起者，发送一个SYN消息给服务器，该服务器端正在监听某个TCP端口。服务器接收该消息并发送一个SYN-ACK消息，客户端接受到该消息之后会再回一个ACK消息。一旦服务器收到ACK消息，TCP连接就建立成功，准备数据传输了。另一方面，UDP是无连接的协议，和点对点连接之前不需要发送消息。这就是为什么，UDP更加适合消息的多播发布，从单个点向多个点传输消息。

• 可靠性不同

TCP提供交付保证,这意味着一个使用TCP协议发送的消息是保证交付给客户端的。如果消息在传输过程中丢失,那么它将重发,这是由TCP协议本身控制的。另一方面,UDP是不可靠的,它不提供任何交付的保证。一个数据报包在运输途中可能会丢失。这就是为什么UDP是不适合保证交付的项目。

• 有序性

除了提供交付保证，为TCP也保证了消息的有序性。该消息将以从服务器端发出的同样的顺序发送到客户端，尽管这些消息到网络的另一端时可能是无序的。TCP协议将会为你排好序。UDP不提供任何有序性或序列性的保证。数据包将以任何可能的顺序到达。这就是为什么TCP是适合需要顺序交付方式的应用，尽管有基于UDP的协议通过使用***和重传来提供有序和可靠性的应用，如TIBCO Rendezvous，他实际上就是一个基于UDP的应用。

• 数据边界

TCP不保存数据的边界，而UDP保证。在传输控制协议，数据以字节流的形式发送，并没有明显的标志表明传输信号消息（段）的边界。在UDP中，数据包单独发送的，只有当他们到达时，才会再次集成。包有明确的界限来哪些包已经收到，这意味着在消息发送后，在接收器接口将会有一个读操作，来生成一个完整的消息。虽然TCP也将在收集所有字节之后生成一个完整的消息，但是这些信息在传给传输给接受端之前将储存在TCP缓冲区，以确保更好的使用网络带宽

• 速度

总而言之，TCP速度比较慢，而UDP速度比较快，因为TCP必须创建连接，以保证消息的可靠交付和有序性，他需要做比UDP多的多的事。这就是为什么UDP更适用于对速度比较敏感的应用，例如：在线视频媒体，电视广播和多人在线游戏。

• 重量级vs轻量级

由于上述的开销，TCP被认为是重量级的协议，而与之相比，UDP协议则是一个轻量级的协议。因为UDP传输的信息中不承担任何间接创造连接，保证交货或秩序的的信息。这也反映在用于承载元数据的头的大小。

• 头大小

TCP具有比UDP更大的头。一个TCP数据包报头的大小是20字节，UDP数据报报头是8个字节。TCP报头中包含***，ACK号，数据偏移量，保留，控制位，窗口，紧急指针，可选项，填充项，校验位，源端口和目的端口。而UDP报头只包含长度，源端口号，目的端口，和校验和。

• 拥塞或流控制

TCP有流量控制。在任何用户数据可以被发送之前，TCP需要三数据包来设置一个套接字连接。TCP处理的可靠性和拥塞控制。另一方面，UDP不能进行流量控制。

• 用法和应用

在互联网中，TCP和UDP都运行在哪些环境中了？在了解了TCP和UDP之间的关键差异之后，我们可以很容易地得出结论，哪种情况适合他们。由于TCP提供可靠交付和有序性的保证，它是最适合需要高可靠并且对传输时间要求不高的应用。UDP是更适合的应用程序需要快速，高效的传输的应用，如游戏。UDP是无状态的性质，在服务器端需要对大量客户端产生的少量请求进行应答的应用中是非常有用的。在实践中，TCP被用于金融领域，如FIX协议是一种基于TCP的协议，而UDP是大量使用在游戏和娱乐场所。

8、什么是三次握手四次挥手？

原文：https://blog.csdn.net/qq_38950316/article/details/81087809

• 三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

• 四次挥手

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其***为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的***seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的***为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的***是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题3】为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始***进行协商，这个***在握手过程中被发送和确认。

       现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的***，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

9、请描述OSI 的七层模型都有哪些？

原文链接：https://blog.csdn.net/meism5/article/details/90414270

OSI模型分为七层，自下而上为 物理层（Physical Layer）、数据链路层（Data Link Layer）、网络层（Network Layer）、传输层（Transport Layer）、会话层（Session Layer）、表达层（Presentation Layer）、应用层（Application Layer）。

 

10、dns是什么？请描述dns的工作原理

DNS（Domain Name Server，域名服务器）是进行域名(domain name)和与之相对应的IP地址 (IP address)转换的服务器。DNS中保存了一张域名(domain name)和与之相对应的IP地址 (IP address)的表，以解析消息的域名。

原理：

• 客户机提出域名解析请求，并将该请求发送给本地的域名服务器。
• 当本地的域名服务器收到请求后，就先查询本地的缓存，如果有该纪录项，则本地的域名服务器就直接把查询的结果返回；如果本地的缓存中没有该纪录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域) 的主域名服务器的地址。
• 本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址。
• 重复第四步，直到找到正确的纪录。
• 本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

11、请描述一次完整的HTTP请求过程

• TCP建立连接

HTTP协议是基于TCP协议来实现的，因此首先就是要通过TCP三次握手与服务器端建立连接，一般HTTP默认的端口号为80；

• 浏览器发送请求命令

一旦建立了 TCP 连接，Web 浏览器就会向 Web 服务器发送请求命令。例如：GET/hello/index.jsp HTTP/1.1。浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息(例：Accept ,User-Agent 等?)，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

• 服务器应答

客户机向服务器发出请求后，服务器会客户机进行应答，应答内容包括：协议的版本号和应答状态码 ：HTTP/1.1 200 OK，响应头信息来记录服务器自己的数据，被请求的文档内容。最后发送一个空白行来表示头信息的发送到此为结束，接着以Content-Type响应头信息所描述的格式发送用户所请求的实际数据。

• 服务器断开TCP连接

一般情况下，一旦 服务器向浏览器发送了请求的数据，它就要关闭 TCP 连接，但是如果浏览器或者服务器在其头信息加入了这行代码：Connection:keep-alive，就会保持此连接状态，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

• 浏览器接受到服务器响应的数据

浏览器解析服务器应答回来的 html 代码和css，和js代码；进行页面的渲染呈现给用户。

12、请描述Cookies和session区别是什么？

• session存放在服务器端，cookie存放在客户端。
• session会随着会话的结束而关闭，cookie则存放在客户端浏览器上长期有效。
• session保存的是对象，cookie保存的是字符串
• 存放在cookie里的信息容易泄露，通常只保存不重要的信息，重要的信息放在session中

13、请描述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方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；

在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；

14、请描述HTTPS和HTTP的区别是什么？

数据加密传输，是HTTP和HTTPS之间的本质性区别。HTTPS基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。功能越强大的证书费用越高。

• http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
• SEO方面：在2015年之前百度是无法收录HTTPS页面的，不过自从2015年5月份百度搜索全站HTTPS加密后，就已经可以收录HTTPS了。谷歌则是从2014年起便开始收录HTTPS页面，并且HTTPS页面权重比HTTP页面更高。从SEO的角度来说，HTTPS和HTTP区别不大，甚至HTTPS效果更好。
• 性能问题：https做了加密就意味着客户端服务端也需要附带解密步骤，相比来说，在通讯快捷上，性能有所不如http。
• 经济方面
  （1）、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
  （2）、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
  （3）、HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。
  （4）、HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的VPS的平均成本会上去。
  （5）、HTTPS协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。

15、请描述session 的工作原理？

Session又称为会话控制。由于HTTP是无状态协议，为了保持浏览器与服务器之间的联系，才有了Session。Session就是用于在服务器端保存用户状态的协议。通常用来保存用户的登录状态。

当用户访问到一个服务器，服务器首先检查这个用户发来的请求里是否包含了一个SESSION ID，如果包含了一个SESSION ID，则说明之前该用户已经登陆过并为此用户创建过SESSION，那服务器就按照这个SESSION ID把这个SESSION在服务器的内存中查找出来，如果客户端请求里不包含有SESSION ID，则为该客户端创建一个SESSION并生成一个与此SESSION相关的SESSION ID。这个SESSION ID是唯一的、不重复的、不容易找到规律的字符串，这个SESSION ID将被在本次响应中返回到客户端保存，而保存这个SESSION ID的正是COOKIE，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。