面试季-网络安全常见面试题整理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)。

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

• 确保使用密码专用算法存储密码，如：Argon二、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天，且一般经过外部检测方检测，而不是经过内部流程或监控检测。

如何防止：

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

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

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

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

二、重要协议分布层

三、请描述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查询失败。

四、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秒时间就是抑制计时器的时间，在此期间，路由器不会用它接收到的新信息对路由表进行更新，这样可以为网路的收敛提供一段额外的时间。
•  触发路由更新——当某个路由度量发生改变时，路由器只发送与改变有关的路由，并不发送完整的路由表。

五、什么是RARP？工做原理

归纳： 反向地址转换协议，网络层协议，RARP与ARP工做方式相反。 RARP使只知道本身硬件地址的主机可以知道其IP地址。RARP发出要反向解释的物理地址并但愿返回其IP地址，应答包括可以提供所需信息的RARP服务器发出的IP地址。

原理：

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

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

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

六、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报文，以检测链路状态，保证链路始终是正常的。

七、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是大量使用在游戏和娱乐场所。

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

原文：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个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭链接。

九、请描述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）。

 

十、dns是什么？请描述dns的工做原理

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

原理：

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

十一、请描述一次完整的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代码；进行页面的渲染呈现给用户。

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

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

1三、请描述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方式；

1四、请描述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协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。
  
  
  
  
  

1五、请描述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，这样在交互过程当中浏览器能够自动的按照规则把这个标识发送给服务器。