计算机网络面试题及答案（计算机网络面试大总结）
本文分文五大部分 ，第一部分总纲说明计算机网络层次划分的三种模型 ，一到四部分以TCP/IP协议模型作为划分标准 ，分别说明各层作用和最常见的面试题 ，最后总结网络综合面试题 ，历时六天全文一千字 。
其他经典面试题参考程序员田同学一 、总纲
写过代码的同学就多多少少接触过GET 、POST 、HTTP 、TCP等名词 ，很多基础不扎实的同学并不知道它们都是什么东西 ，其实这些名词都是计算机网络中各层的协议 ，计算机网络分层主要是三种分法 ，OSI七层模型 、TCP\IP四层模型 、学习型五层协议 。
1 、计算机各层协议及作用
OSI 的七层协议体系结构的概念清楚 ，理论也较完整 ，但它既复杂又不实用 。
TCP/IP 体系结构则不同 ，但它现在却得到了非常广泛的应用 。TCP/IP 是一个四层体系结构 ，它包含应用层 ，运输层 ，网际层和网络接口层（用网际层这个名字是强调这一层是为了解决不同网络的互连问题） ，不过从实质上讲 ，TCP/IP 只有上面的三层 ，因为下面的网络接口层并没有什么具体内容 。
因此在学习计算机网络的原理时往往采用折中的办法 ，即综合 OSI 和 TCP/IP 的优点 ，采用 一种只有五层协议的体系结构 ，这样既简洁又能将概念阐述清楚 ，有时为了方便 ，也可把底下两层称为网络接口层 。
TCP（传输控制协议）和IP（网际协议） 是先定义的两个核心协议 ，所以才统称为TCP/IP协议族
七层网络体系结构各层的主要功能：
应用层：为应用程序提供交互服务 。在互联网中的应用层协议很多 ，如域名系统DNS ，支持万维网应用的HTTP协议 ，支持电子邮件的SMTP协议等 。
表示层：主要负责数据格式的转换 ，如加密解密 、转换翻译 、压缩解压缩等 。
会话层：负责在网络中的两节点之间建立 、维持和终止通信 ，如服务器验证用户登录便是由会话层完成的 。
运输层：有时也译为传输层 ，向主机进程提供通用的数据传输服务 。该层主要有以下两种协议：
TCP：提供面向连接的 、可靠的数据传输服务； UDP：提供无连接的 、尽最大努力的数据传输服务 ，但不保证数据传输的可靠性 。网络层：选择合适的路由和交换结点 ，确保数据及时传送 。主要包括IP协议 、路由器 。
数据链路层：数据链路层通常简称为链路层 。将网络层传下来的IP数据包组装成帧 ，并再相邻节点的链路上传送帧 ，包括交换机 。
物理层：实现相邻节点间比特流的透明传输 ，尽可能屏蔽传输介质和通信手段的差异 。
本章节是学习下面章节的基础 ，只有明白网络分层中各层的作用才能准备判断TCP 、HTTP位于网络协议中的哪一层 。
二 、应用层
应用层的任务是通过应用进程间的交互来完成特定网络应用 。应用层协议定义的是应用进程间的通信和交互的规则 。
对于不同的网络应用需要不同的应用层协议 。在互联网中应用层协议很多 ，如域名系统 DNS ，支持万维网应用的 HTTP 协议 ，支持电子邮件的 SMTP 协议等等 。
1 、http和https区别
①HTTP请求由三部分组成①请求行 ，请求方法字段 、URL字段 、HTTP协议版本（例如：GET /index.html HTTP/1.1）
②请求头 ，key-value形式（User-Agent：产生请求的浏览器类型 ，Accept：客户端可识别的内容类型列表 ，Host：主机地址）
③请求数据 ，POST请求中key-value形式发送 。
②HTTP版本更新HTTP 协议有 HTTP/1.0 版本和 HTTP/1.1 版本 。HTTP1.1 默认保持长连接（当一个网页打开完成后 ，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭 ，如果客户端再次访问这个服务器上的网页 ，会继续使用这一条已经建立的连接 。Keep-Alive不会永久保持连接 ，它有一个保持时间 ，可以在不同的服务器软件（如Apache）中设定这个时间 。实现长连接要客户端和服务端都支持长连接 。）数据传输完成了保持 TCP 连接不断开（不发 RST 包 、不四次握手） ，等待在同域名下继续用这个通道传输数据 。
在 HTTP/1.0 中 ，默认使用的是短连接（浏览器和服务器每进行一次HTTP操作 ，就建立一次连接 ，但任务结束就中断连接） 。也就是说 ，浏览器和服务器每进行一次 HTTP 操作 ，就建立一次连接 ，任务结束就中断连接 。从 HTTP/1.1 起 ，默认使用的是长连接 ，用以保持连接特性 。
HTTP 1.0
短连接：每次发送请求都要重新建立tcp请求 ，即三次握手 ，非常浪费性能 无host头域 ，也就是http请求头里的host ， 不允许断点续传 ，而且不能只传输对象的一部分 ，要求传输整个对象HTTP 2.0
1.头部压缩 ，双方各自维护一个header的索引表 ，使得不需要直接发送值 ，通过发送key缩减头部大小
2.多路复用 ，使用多个stream ，每个stream又分帧传输 ，使得一个tcp连接能够处理多个http请求
3.可以使用服务端推送
HTTP3.0
基于google的QUIC协议 ，而quic协议是使用udp实现的 减少了tcp三次握手时间 ，以及tls握手时间 解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题 优化了重传策略 ，重传包和原包的编号不同 ，降低后续重传计算的消耗 连接迁移 ，不再用tcp四元组确定一个连接 ，而是用一个64位随机数来确定这个连接 更合适的流量控制 ③HTTPS原理在学习HTTPS原理之前我们先学习两个计算机网络中加密的概念 。
对称加密：通信双方都使用同一个秘钥进行加密和解密 。无法解决首次把秘钥发送给对方时 ，很容易被截获的问题 。
非对称加密：公钥和私钥组成一个密钥对 ，用私钥加密的数据 ，只有对应的公钥才能解密 ，用公钥加密的数据 ，只有对应的私钥才能解密 。通信双方的手里都有一套自己的密钥对 ，通信之前双方会先把自己的公钥都发送给对方 ，然后 对方拿这个公钥来加密要发送的数据 ，接收方用自己的私钥对其解密 。问题是速度慢 。
将HTTP变成HTTPS时 ，这时候需要一个 证书颁发机构（CA） ，证书中包括签发者 、证书用途 、使用者的公钥私钥和 Hash 算法 、证书到期时间等 。另外使用 数字签名 这一技术：使用 CA 自带的 Hash 算法对证书内容进行 Hash 得到一个摘要（指纹） ，再用 CA 的私钥加密 ，生成数字签名 。接收者收到证书时 ，使用同样的 Hash 算法再次生成消息摘要 ，然后用 CA 的公钥对数字签名解密 ，将它和消息摘要对比 ，就知道有没有被篡改 。
④HTTPS和HTTP对比 区别 HTTP HTTPS 协议 运行在 TCP 之上 ，明文传输 ，客户端与服务器端都无法验证对方的身份 身披 SSL( Secure Socket Layer )外壳的 HTTP ，运行于 SSL 上 ，SSL 运行于 TCP 之 上 ， 是添加了加密和认证机制的 HTTP 。 端口 40 443 资源消耗 较少 由于加解密处理 ，会消耗更 多的 CPU 和内存资源 开销 无需证书 需要证书 ，而证书一般需要向认证机构购买 加密机制 无 共享密钥加密和公开密钥加密并用的混合加密机制 安全性 弱 由于加密机制 ，安全性强2 、GET和POST区别
最重要的区别就是get产生一个TCP数据包 ，而post产生两个TCP数据包 。
对于get的请求 ，浏览器会把浏览器的header和data一起发送出去 ，服务器响应200 ，对于post ，浏览器先发送header ，浏览器响应100 ，浏览器再发送data ，服务器响应200 ，也就是说get只需要汽车跑一趟就把货送到了 ，而post需要跑两趟 ，第一趟先去和服务器打个招呼告诉它我等下要送货过来 ，开门迎接我 ，第二趟就是把货送过去 。
据研究 ，在网络环境好的情况下 ，发一次包的时间和发两次包的时间查基本可以无视 ，而在网络环境差的情况下 ，两次包的TCP在验证数据包完整性上有很大的优势 ，所以不推荐使用get来优化性能 ，当然 ，并不是所有的浏览器都会在post中发两次tcp包 ，火狐浏览器就只发一次
下面我们看看get和post应用上的区别：
①get的参数通过URL传递 ，post放在request body（请求头）中
②get在URL中的参数是有长度限制的 ，而post没有 。GET 方式提交的数据最多只能是 1024 字节 ，理论上POST 没有限制 ，可传较大量的数据 。其实这样说是错误的 ，不准确的：“GET 方式提交的数据最多只能是 1024 字节" ，因为 GET 是通过 URL 提交数据 ，那么 GET 可提交的数据量就跟URL 的长度有直接关系了 。而实际上 ，URL 不存在参数上限的问题 ，HTTP 协议规范没有对 URL 长度进行限制 。这个限制是特定的浏览器及服务器对它的限制 。IE 对URL 长度的限制是2083 字节(2K+35) 。对于其他浏览器 ，如Netscape 、FireFox 等 ，理论上没有长度限制 ，其限制取决于操作系统的支持 。
③get只能进行URL编码 ，而post支持多种 。
④get只接受ASSIC字符 ，而post没有限制 。
⑤post比get安全 ，因为get的参数暴露在URL中 。
3 、常见HTTP状态码
状态码 含义 200 OK ，表示从客户端发来的请求在服务器端被正确处理 204 No content ，表示请求成功 ，但响应报文不含实体的主体部分 206 Partial Content ，进行范围请求成功 301 永久性重定向 ，表示资源已被分配了新的 URL 302 临时性重定向 ，表示资源临时被分配了新的 URL 303 表示资源存在着另一个 URL ， 应使用 GET 方法获取资源 （对于 301/302/ 303响应 ，几乎所有浏览器都会删除报文主体并 自动用 GET重新请求） 304 表示服务器允许访问资源 ，但请求未满足条件的情况 307 临时重定 向 ，和302 含义类似 ，但是期望客户端保持请求方法不变向新的地址发出请求 400 请求报文存在语法错误 401 表示发送的请求需要有通过 HTTP 认证的认证信息 403 表示对请求资源的访问被服务器拒绝 ，可在实体主体部分返回原因描述 404 示在服务器上没有找到请求的资源 500 表 示服务器端在执行请求时发生了错误 501 表示服务器不支持当前请求所需要的某个功能 503 表明服务器暂时处于超负载或正在停机维护 ，无法处理请求三 、传输层
1 、TCP和UDP的区别
①TCP面向连接 ，而UDP是无连接的
②TCP可靠（HTTP 、HTTPS 、FTP） ，UDP不可靠（视频 、DNS）
③TCP只支持点对点通信 ，而UDP支持1对1 ，1对多 ，多对1 ，多对多的通信模式
④TCP是面向字节流的 ，UDP是面向报文的
⑤TCP有拥塞控制 ，UDP没有拥塞控制 ，适合媒体通信
⑥TCP首部开销（20字节）比UDP首部开销（8个字节）要大
2 、TCP三次握手四次挥手*
①标志位标志位一共有6种 ，分别是：
SYN(synchronous)： 发送/同步标志 ，用来建立连接 ，和下面的第二个标志位ACK搭配使用 。连接开始时 ，SYN=1 ，ACK=0 ，代表连接开始但是未获得响应 。当连接被响应的时候 ，标志位会发生变化 ，其中ACK会置为1 ，代表确认收到连接请求 ，此时的标志位变成了 SYN=1 ，ACK=1 。 ACK(acknowledgement)：确认标志 ，表示确认收到请求 。 PSH(push) ：表示推送操作 ，就是指数据包到达接收端以后 ，不对其进行队列处理 ，而是尽可能的将数据交给应用程序处理； FIN(finish)：结束标志 ，用于结束一个TCP会话； RST(reset)：重置复位标志 ，用于复位对应的TCP连接 。 URG(urgent)：紧急标志 ，用于保证TCP连接不被中断 ，并且督促中间层设备尽快处理 。此外 ，还有两个序号：
Sequence number ：顺序号 ，发送数据包中的第一个字节的序列号 ，一般为小写的seq 。
Acknowledge number：确认号 ，一般为小写的ack ，响应前面的seq ，值为seq+1 。
在理解三次握手和四次挥手时结合图 ，看三到四遍便可理解
②三次握手（请求链接）所谓三次握手 ，是指建立一个TCP连接时 ，需要客户端和服务器总共发送3个包 。 三次握手的目的是连接服务器指定端口 ，建立TCP连接,并同步连接双方的顺序号和确认号并交换 TCP信息 。
第一次握手：客户端Client发送位码为SYN＝1 ，随机产生seq=x的数据包到服务器 ，服务器Server由SYN=1知道 ，客户端Client要求建立联机；
第二次握手：服务器Server收到请求后要确认联机信息 ，向客户端Client发送ack=(客户端Client请求连接时的seq)+1 ，SYN=1 ，ACK=1 ，产生seq=y的包,代表接收到连接请求并且向客户端再次确认；
第三次握手：客户端Client收到后检查ack是否正确 ，即第一次发送的seq+1 ，以及位码ACK是否为1 ，代表收到了服务器端发过来的确认信息 。之后客户端Client会再向服务器发送ack=(服务器Server的seq+1) ，ACK=1 ，服务器Server收到后确认ack 值与ACK=1 ，连接建立成功 。
③四次挥手（请求断开）客户端Client进程发出连接释放报文 ，并且停止发送数据 。其中FIN=1 ，顺序号为seq=m（等于前面已经传送过来的数据的最后一个字节的序号加1） ，此时 ，客户端Client进入FIN-WAIT-1（终止等待1）状态 。 TCP规定 ，FIN报文段即使不携带数据 ，也要消耗一个序号 。
服务器Server收到连接释放报文 ，发出确认报文 ，ACK=1 ，ack=m+1 ，并且带上自己的顺序号seq=n ，此时 ，服务器Server就进入了CLOSE-WAIT（关闭等待）状态 。TCP服务器通知高层的应用进程 ，客户端Client向服务器的方向就释放了 ，这时候处于半关闭状态 ，即客户端Client已经没有数据要发送了 ，但是服务器Server若发送数据 ，客户端Client依然要接受 。这个状态还要持续一段时间 ，也就是整个CLOSE-WAIT状态持续的时间 。
客户端Client收到服务器Server的确认信息后 ，此时 ，客户端Client就进入FIN-WAIT-2（终止等待2）状态 ，等待服务器Server发送连接释放报文（在这之前还需要接受服务器Server发送的最后的数据） 。
服务器Server将最后的数据发送完毕后 ，就向客户端发送连接释放报文 ，FIN=1 ，ack=m+1 ，由于在半关闭状态 ，服务器Server很可能又发送了一些数据 ，假定此时的顺序号为seq=p ，此时 ，服务器Server就进入了LAST-ACK（最后确认）状态 ，等待客户端Client的确认 。
客户端Client收到服务器Server的连接释放报文后 ，必须发出确认 ，ACK=1 ，ack=p+1 ，而自己的顺序号是seq=m+1 ，此时 ，客户端Client就进入了TIME-WAIT（时间等待）状态 。注意此时TCP连接还没有释放 ，必须经过2*MSL（最长报文段寿命）的时间后 ，当客户端Client撤销相应的TCB（保护程序）后 ，才进入CLOSED状态 。TIME_WAIT 需要等待 2MSL ，在大量短连接的情况下 ，TIME_WAIT会太多 ，这也会消耗很多系统资源 。对于服务器来说 ，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求） ，由浏览器来主动断开连接 ，可以一定程度上减少服务器的这个问题 。
服务器Server只要收到了客户端Client发出的确认 ，立即进入CLOSED状态 。同样 ，撤销TCB后 ，就结束了这次的TCP连接 。可以看到 ，服务器Server结束TCP连接的时间要比客户端Client早一些 。
④握手三次挥手四次原因服务器在收到客户端的 FIN 报文段后 ，可能还有一些数据要传输 ，所以不能马上关闭连接 ，但是会做出应答 ，返回 ACK 报文段.
接下来可能会继续发送数据 ，在数据发送完后 ，服务器会向客户单发送 FIN 报文 ，表示数据已经发送完毕 ，请求关闭连接 。服务器的ACK和FIN一般都会分开发送 ，从而导致多了一次 ，因此一共需要四次挥手 。
⑤二次握手行不行（1）为了防止已经失效的连接请求报文突然又传送到了服务器端（网络堵塞的原因）
如果客户端发出的连接请求报文并未丢失而是在某个网络结点长时间堵塞了 ，导致延误到连接释放以后的某个时间才到达服务器 ，这时服务器误以为是客户端发出了一个新的连接请求 ，于是就向客户端发送确认数据包 ，同意建立连接 。
如果不采用三次握手 ，那么只要服务器端发送确认数据包 ，连接就建立成功了 ，由于客户端并未发出连接请求 ，所以不会理睬服务器的确认 ，也不与服务器通信 ，而这个时候服务器一直在等待客户端发送数据 ，这样服务器就白白浪费了资源 ，如果采用三次握手 ，那么服务器端密钥收到来自客户端的确认 ，就知道客户端并没有请求建立连接 ，就不会建立连接 。
（2）三次握手才能让双方均确认自己和对方的发送和接收能力都正常 。
第一次握手：客户端只是发送处请求报文段 ，什么都无法确认 ，而服务器可以确认自己的接收能力和对方的发送能力正常；
第二次握手：客户端可以确认自己发送能力和接收能力正常 ，对方发送能力和接收能力正常；
第三次握手：服务器可以确认自己发送能力和接收能力正常 ，对方发送能力和接收能力正常；
可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常 ，这样就可以愉快地进行通信了 。
（3）告知对方自己的初始序号值 ，并确认收到对方的初始序号值 。
TCP 实现了可靠的数据传输 ，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段 ，通过这两个字段双方都可以知道在自己发出的数据中 ，哪些是已经被对方确认接收的 。这两个字段的值会在初始序号值得基础递增 ，如果是两次握手 ，只有发起方的初始序号可以得到确认 ，而另一方的初始序号则得不到确认 。
⑥挥手三次行不行三次和四次的区别就在于服务器连续给客户端发了两个报文 ，那把这两个报文合并成一个不可以吗？为什么呢？答案是不可以 ，首先客户端发来请求断开连接的报文 ，假设这个时候服务器端仍然在发送报文（因为是全双工） ，如果是三次挥手 ，那么服务器只会确认客户的断开请求 ，客户端不会说我还有数据没有发送完 ，你要等等我 ，这样会导致客户端接收的数据不完整 。
如果是四次挥手 ，那么服务器接收到客户的断开请求 ，会先说可以断开 ，但是你要先等我发送完剩余的数据 ，然后说我剩余的数据发送完了 ，我要和你断开连接
挥手过程之所以比握手过程多一次 ，就是因为握手过程只需要处理连接 ，而挥手过程需要处理连接和数据 。
3 、TCP协议保证可靠性
TCP主要提供了数据表检验和 、序列号/确认应答 、超时重传 、滑动窗口 、拥塞控制和流量控制等方法实现了可靠性传输 。
数据包校验：目的是检测数据在传输过程中的任何变化 ，若校验出包有错 ，则丢弃报文段并且不给出响应 ，这时TCP发送数据端超时后会重发数据 。
序列号/确认应答：
序列号的作用不仅仅是应答的作用 ，有了序列号能够将接收到的数据根据序列号排序 ，并且去掉重复序列号的数据 。
TCP传输的过程中 ，每次接收方收到数据后 ，都会对传输方进行确认应答 。也就是发送ack报文 ，这个ack报文当中带有对应的确认序列号 ，告诉发送方 ，接收到了哪些数据 ，下一次的数据从哪里发 。
滑动窗口：滑动窗口既提高了报文传输的效率 ，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常 。
超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间 ，如果超过了这个时间会被认为是丢包了 ，需要重传 。最大超时时间是动态计算的 。
拥塞控制：在数据传输过程中 ，可能由于网络状态的问题 ，造成网络拥堵 ，此时引入拥塞控制机制 ，在保证TCP可靠性的同时 ，提高性能 。
流量控制：TCP连接的每一方都有固定大小的缓冲空间 。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据 ，这可以防止较快主机致使较慢主机的缓冲区溢出 ，这就是流量控制 。TCP使用的流量控制协议是可变大小的滑动窗口协议 。
4 、TCP的滑动窗口
在进行数据传输时 ，如果传输的数据比较大 ，就需要拆分为多个数据包进行发送 。TCP 协议需要对数据进行确认后 ，才可以发送下一个数据包 。这样一来 ，就会在等待确认应答包环节浪费时间 。
为了避免这种情况 ，TCP引入了窗口概念 。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值 。
滑动窗口（Sliding window）是一种流量控制技术 。早期的网络通信中 ，通信双方不会考虑网络的拥挤情况直接发送数据 。由于大家不知道网络拥塞状况 ，同时发送数据 ，导致中间节点阻塞掉包 ，谁也发不了数据 ，所以就有了滑动窗口机制来解决此问题
滑动窗口协议是用来改善吞吐量的一种技术 ，即容许发送方在接收任何应答之前传送附加的包 。接收方告诉发送方在某一时刻能送多少包（称窗口尺寸） 。
TCP中采用滑动窗口来进行传输控制 ，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据 。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据 。当滑动窗口为0时 ，发送方一般不能再发送数据报 ，但有两种情况除外 ，一种情况是可以发送紧急数据 ，例如 ，允许用户终止在远端机上的运行进程 。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小 。
5 、TCP拥塞机制
拥塞控制就是防止过多的数据注入网络 ，造成网络堵塞 ，拥塞控制和流量控制不同 ，拥塞控制是一个全局性过程 ，而流量控制是点对点通信的控制 ，拥塞控制的方法主要有四个算法：
①慢启动：不要一开始就发送大量数据 ，先探测一下网络的拥塞程度 ，也就是说从小到大逐渐增加拥塞窗口的大小
②拥塞避免（AMDI：加法增大乘法减小）：让拥塞窗口缓慢增大 ，每经过一个往返时间就将拥塞窗口+1,缓慢增大拥塞窗口
③快重传：发送方只要一收到三个重复的确认就应该立即重传对方并未收到的报文段 ，而不必继续等待重传计时器到达重传时间 ，快重传并不是取消重传计时器 ，而是在某些情况下更早的重传丢失的报文
④快恢复：为了减少因为拥塞导致的数据包丢失带来的重传时间 ，快重传的机制是：
接收方如果一个包丢失 ，则对后续的包继续发送针对该包的重传请求； 一旦发送方接收到三个一样的确认 ，就知道该包之后出现了错误 ，立刻重传该包； 此时发送方开始执行“快恢复 ”算法； 慢开始门限减半； cwnd设为慢开始门限减半后的数量； 执行拥塞避免算法（高起点 ，线性增长）；6 、SYN攻击
SYN洪泛攻击属于 DOS 攻击的一种 ，它利用 TCP 协议缺陷 ，通过发送大量的半连接请求 ，耗费 CPU 和内存资源 。
原理：
在三次握手过程中 ，服务器发送 [SYN/ACK] 包（第二个包）之后 、收到客户端的 [ACK] 包（第三个包）之前的 TCP 连接称为半连接（half-open connect） ，此时服务器处于 SYN_RECV（等待客户端响应）状态 。如果接收到客户端的 [ACK] ，则 TCP 连接成功 ，如果未接受到 ，则会不断重发请求直至成功 。 SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址 ，向服务器不断地发送 [SYN] 包 ，服务器回复 [SYN/ACK] 包 ，并等待客户的确认 。由于源地址是不存在的 ，服务器需要不断的重发直至超时 。 这些伪造的 [SYN] 包将长时间占用未连接队列 ，影响了正常的 SYN ，导致目标系统运行缓慢 、网络堵塞甚至系统瘫痪 。检测：当在服务器上看到大量的半连接状态时 ，特别是源 IP 地址是随机的 ，基本上可以断定这是一次 SYN 攻击 。
防范：
通过防火墙 、路由器等过滤网关防护 。
通过加固 TCP/IP 协议栈防范 ，如增加最大半连接数 ，缩短超时时间 。
SYN cookies技术 。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改 ，专门用来防范 SYN 洪泛攻击的一种手段 。
7 、建立链接后出现故障
TCP设有一个保活计时器 ，客户端如果出现故障 ，服务器不能一直等下去 ，白白浪费资源 。服务器每收到一次客户端的请求后都会重新复位这个计时器 ，时间通常是设置为2小时 ，若两小时还没有收到客户端的任何数据 ，服务器就会发送一个探测报文段 ，以后每隔75秒钟发送一次 。若一连发送10个探测报文仍然没反应 ，服务器就认为客户端出了故障 ，接着就关闭连接 。
四 、网络层
网络层的任务就是选择合适的网间路由和交换结点 ，确保计算机通信的数据及时传送 。在发送数据时 ，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送 。在 TCP/IP 体系结构中 ，由于网络层使用 IP 协议 ，因此分组也叫 IP 数据报 ，简称数据报 。
互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的 。互联网使用的网络层协议是无连接的网际协议（Intert Prococol） 和许多路由选择协议 ，因此互联网的网络层也叫做网际层或 IP 层 。
1 、IP相关IP地址分类方式一：
IPv4：是一个32位的二进制数 ，通常被分为4个字节 ，表示成 a.b.c.d 的形式.
其中a 、b 、c 、d都是0~255之间的十进制整数 ，那么最多可以表示42亿个 。
IPv6：由于互联网的蓬勃发展 ，IP地址的需求量愈来愈大 ，但是网络地址资源有限 ，使得IP的分配越发紧张 。
为了扩大地址空间 ，拟通过IPv6重新定义地址空间 ，采用128位地址长度 ，每16个字节一组 ，分成 8组十六进制数 ，表示成ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 ，号称可以为全世界的每一粒沙子编上一个网址 ，这样就解决了网络地址资源数量不够的问题 。
IP地址分类方式二：
公网地址( 万维网使用)和 私有地址( 局域网使用) 。192.168.开头的就是私有址址 ，范围即为
192.168.0.0--192.168.255.255 ，专门为组织机构内部使用
2 、APR协议网络层的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查询失败 。
五 、总结
1 、浏览器输入URL的过程
①浏览器查询DNS ，获得域名对应的IP地址（DNS寻址过程）
*先从浏览器缓存找ip ，因为浏览器会缓存DNS记录一段时间
*如果没有找到 ，再从Host文件查找是否有该域名对应的IP
*如果没有找到 ，再从路由器缓存找
*如果没有找到 ，再从DNS缓存找
*如果都没有找到 ，就从浏览器域名服务器向根域名服务器查找 ，没有找到就继续迭代 ，直到找到为止
②浏览器获得IP地址后 ，浏览器向服务器请求连接 ，发起三次握手
③连接建立起来后 ，浏览器向服务器发送http请求
④服务器接收到这个请求 ，并根据路径参数映射到特定的请求处理器进行处理 ，并将视图以及相应的结果返回给浏览器
⑤浏览器解析并渲染视图 ，若遇到对js ，css文件以及静态图片资源的引用 ，重复上述步骤向服务器请求资源
⑥浏览器根据请求到的资源 ，数据渲染页面 ，最终向用户呈现
个人总结二十三种设计模式全套总结：
一 、设计模式概述
二 、设计模式之工厂方法和抽象工厂
三 、设计模式之单例和原型
四 、设计模式之建造者模式
五 、设计模式之代理模式
六 、设计模式之适配器模式
七 、设计模式之桥接模式
八 、设计模式之组合模式
九 、设计模式之装饰器模式
十 、设计模式之外观模式
十一 、设计模式之享元模式
行为型设计模式十二 、设计模式之责任链模式
十三 、设计模式之命令模式
十四 、设计模式之解释器模式
十五 、设计模式之迭代器模式
十六 、设计模式之中介者模式
十七 、设计模式之备忘录模式
十八 、设计模式之观察者模式
十九 、设计模式之状态模式
二十 、设计模式之策略模式
二十一 、设计模式之模板方法模式
二十二 、设计模式之访问者模式
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！