手把手教你如何玩转面试（计算机网络）

        本篇是讲解关于JavaWeb岗位面试方面的一些对于计算机网络知识的整理，当然，不只是需要知道这个方面的内容，还需要掌握其他方面的知识，我都根据自己的经历来进行了整理，方便大家进行系统化的学习，只有多复习多研究，才能对技术有更好的掌握，才能拿到更好的offer。（基于博主真实的企业面试题哦~）

下面是其他方面的知识点，欢迎大家进行浏览

Java基础：https://blog.csdn.net/Cs_hnu_scw/article/details/79635874

数据结构：https://blog.csdn.net/Cs_hnu_scw/article/details/79896717

Web方向：https://blog.csdn.net/Cs_hnu_scw/article/details/79896165

数据库：https://blog.csdn.net/Cs_hnu_scw/article/details/82900559

操作系统：https://blog.csdn.net/Cs_hnu_scw/article/details/79896500

其他方面的知识：https://blog.csdn.net/Cs_hnu_scw/article/details/79896876

1：UDP和TCP的区别？

答：TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。

UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
有些应用场景对可靠性要求不高会用到UPD，比如长视频，要求速率

它们两者之间的区别：

（1）、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

（2）、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
（3）、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
    UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
（4）、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
（5）、TCP首部开销20字节;UDP的首部开销小，只有8个字节

（6）、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

参考博文：TCP和UDP之间的区别

2：UDP应用的场景？UDP的大小？UDP在什么时候容易丢包？丢包会丢一个字节的内容吗？

答：应用场景：1.面向数据报方式

  2.网络数据大多为短消息 
  3.拥有大量Client
  4.对数据安全性无特殊要求

  5.网络负担非常重，但对响应速度要求高

比如，QQ语音，QQ视频，TFTP

大小：UDP是由首部和数据部组成，而首部占8个字节，UDP总长度不能超过65535字节，刚好可以放进到一个IP数据包中；

丢包的原因：1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。

不会丢一字节的内容，因为UDP的首部是8字节，都是以8的倍数内容，所以不存在丢一字节的内容；

点击：关于UDP丢包的详解文章

3：TCP应用的场景？TCP的大小？

答：场景：主要是用在对网络质量有要求的情况下，需要准确无误的进行传输，比如：（1）浏览器，用的HTTP

（2）FlashFXP，用的FTP
（3）Outlook，用的POP、SMTP
（4）Putty，用的Telnet、SSH
（5）QQ文件传输

大小：TCP的首部字节占20个字节，而在以太网中，最大的传输字节为1518字节，而还需要出去18字节的以太网帧头，所以最大就只能是1500字节，另外IP的头还有20个字节，所以TCP传输最大只能是1500-20-20=1460字节；

4：TCP和UDP应用的场景？

答：

5：HTTP和Https的区别是什么？

答：相同点：

大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息、或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

不同点：

1. HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
4. 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
5. HTTP 无需加密，而 HTTPS 对传输的数据进行加密
6. HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 如何工作?

使用 HTTPS 连接时，服务器要求有公钥和签名的证书。当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

1. 浏览器打开一个 TCP 连接
2. 浏览器发送 HTTP 请求到服务器端
3. 服务器发送 HTTP 回应信息到浏览器
4. TCP 连接关闭

SSL 包含如下动作：

1. 验证服务器端
2. 允许客户端和服务器端选择加密算法和密码，确保双方都支持
3. 验证客户端(可选)
4. 使用公钥加密技术来生成共享加密数据
5. 创建一个加密的 SSL 连接
6. 基于该 SSL 连接传递 HTTP 请求

什么时候该使用 HTTPS?

银行网站、支付网关、购物网站、登录页、电子邮件以及一些企业部门的网站应该使用 HTTPS

6：三次握手和四次挥手的过程

答：几个概念： 
【1】seq：序号，占4个字节，范围[0,4284967296],由于TCP是面向字节流的，在一个1个TCP连接中传送字节流中的每一个字节都按照顺序编号，此外序号是循环使用的 
【2】ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，并且TCP规定，在连接建立后所有的传送报文段都必须要把ACK置为1 
【3】SYN：同步序列号，用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段；若对方同意连接，则响应报文中SYN=1，ACK=1 
【4】FIN ：用来释放一个连接，当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接

三次握手：(1)客户端向服务器端发送连接请求包SYN（syn=j），等待服务器回应；

(2)服务器端收到客户端连接请求包SYN（syn=j）后，将客户端的请求包SYN（syn=j）放入到自己的未连接队列，此时服务器需要发送两个包给客户端；
    1.向客户端发送确认自己收到其连接请求的确认包ACK（ack=j+1），向客户端表明已知道了其连接请求
　  2.向客户端发送连接询问请求包SYN（syn=k），询问客户端是否已经准备好建立连接，进行数据通信；
(3)  客户端收到服务器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服务器同意建立连接，此时需要发送连接已建立的消息给服务器；
　　向服务器发送连接建立的确认包ACK（ack=k+1），回应服务器的SYN（syn=k）告诉服务器，我们之间已经建立了连接，可以进行数据通信。

为什么不能只两次握手？
    有了三次握手的详细步骤，就可以分析为什么需要三次握手而不是两次握手了。

    三次握手的目的：消除旧有连接请求的SYN消息对新连接的干扰，同步连接双方的序列号和确认号并交换TCP 窗口大小信息。采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

为什么不能是四次握手呢？

      大家应该知道通信中著名的蓝军红军约定， 这个例子说明， 通信不可能100%可靠， 而上面的三次握手已经做好了通信的准备工作， 再增加握手， 并不能显著提高可靠性， 而且也没有必要。

知识延伸-------------通信中的红军蓝军约定：

大概内容如下：红军和蓝军都想消灭一波敌人，但是单凭他们一个军队的力量都不足以消灭这波敌人，因此他们想到了一起合作，于是红军向蓝军发了一封电报，内容是约定好早上8点一起向敌军进攻，由于他们不确定蓝军是否一定能收到电报，所以只有收到蓝军的回复之后才会进行进攻，而蓝军也是同样的想法，因为他们不确定红军一定能收到自己的回复而在约定好的时间发动进攻，所以他们只有收到红军的回复后才发动进攻…… 
问怎样才能保证这次战役一定胜利呢？答案是不可能的，因为双方都对于自己发出的消息对方是否一定接收得到存在质疑，所以，这样的通信将一直进行下去，结果将是使胜利的几率一直接近100%，但是却永远达不到100%，那么有什么好方法解决这种现状呢？一种方法就是提前约定好，在几次通信之后，就发动进攻，而不是一直继续下去。而TCP协议就是使用这种方法，在三次通信之后就建立连接，在这个例子之中就是：红军率先发送消息，蓝军收到消息之后立即回复，红军收到蓝军的回复后立即向蓝军发送消息确认自己已收到蓝军的回复，之后红军不管蓝军是否收到自己的回复，都按约定好的时间发动进攻，而蓝军只有收到红军第二次发的消息之后才按计划发动进攻。

需四次挥手原因：由于TCP的半关闭特性，TCP连接时双全工（即数据在两个方向上能同时传递），因此，每个方向必须单独的进行关闭。这个原则就是：当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向上的连接。当一端收到一个FIN后，它必须通知应用层另一端已经终止了那个方向的数据传送。即收到一个FIN意味着在这一方向上没有数据流动了。

目的：保证服务器与客户端都能完全的接受对方发送的数据。
第一次挥手：客户端发送一个FIN，用来关闭客户端到服务器的数据传送，也就是客户端告诉服务器：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，客户端依然会重发这些数据)，但是，此时客户端还可 以接受数据。
     FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
第二次挥手：服务器收到FIN包后，发送一个ACK给对方并且带上自己的序列号seq，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
第三次挥手：服务器发送一个FIN，用来关闭服务器到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么客户端最后还要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

7：为什么连接的时候是三次握手，关闭的时候却是四次挥手？

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

8：OSI七层模型和TCP/IP四层模型

答：

https://blog.csdn.net/cwg_1992/article/details/17504343

https://blog.csdn.net/leiflyy/article/details/50096567

9：从url到页面的过程到底是如何进行的？(重点的重点)

答：这个题，在自己面百度和腾讯的时候都有被问到；

https://blog.csdn.net/mevicky/article/details/46789381

https://blog.csdn.net/samjustin1/article/details/52650520

https://blog.csdn.net/ty987654/article/details/78007319

10：网络管理应具有哪几个功能？

答：（1）配置管理（2）性能管理（3）故障管理（4）安全管理（5）计费管理

11：传输层的拥塞控制？

答：https://blog.csdn.net/u010796790/article/details/52853539

12：请说说QQ在哪些地方用的是TCP协议，哪些用的是UDP协议？

答：https://blog.csdn.net/smartsmile2012/article/details/51606430?locationNum=5&fps=1

13：从一台主机到另外一台主机发送一个数据包在传输的过程中，其IP地址和MAC地址是如何进行变化的？

答：比如：假设网络上要将一个数据包（名为PAC）由北京的一台主机（名称为A，IP地址为IP_A，MAC地址为MAC_A）发送到华盛顿的一台主机（名称为B，IP地址为IP_B，MAC地址为MAC_B）。

（1）这两台主机之间不可能是直接连接起来的，因而数据包在传递时必然要经过许多中间节点（如路由器，服务器等等），我们假定在传输过程中要经过C1、C2、C3（其MAC地址分别为M1，M2，M3）三个节点。
（2）A在将PAC发出之前，先发送一个ARP请求，找到其要到达IP_B所必须经历的第一个中间节点C1的MAC地址M1，然后在其数据包中封装（Encapsulation）这些地址：IP_A、IP_B，MAC_A和M1。
（3）当PAC传到C1后，再由ARP根据其目的IP地址IP_B，找到其要经历的第二个中间节点C2的MAC地址M2，然后再将带有M2的数据包传送到C2。
（4）如此类推，直到最后找到带有IP地址为IP_B的B主机的地址MAC_B，最终传送给主机B。
（5）在传输过程中，IP_A、IP_B和MAC_A不变，而中间节点的MAC地址通过ARP在不断改变（M1，M2，M3），直至目的地址MAC_B。

温馨提示：（1）在数据包的传输过程中，源IP地址和目的IP地址是不会发生变化的，变化的只是在传输过程中的MAC地址

（2）路由器是在OSI模型中的网络层，交换机是在OSI模型中的数据链路层，集线器是在OSI模型中的物理层

（3）Ping 发出的是ICMP协议

更多的详情可以参考：重点文章：https://blog.csdn.net/thisispan/article/details/7587998

（1）为什么需要IP地址和MAC地址https://blog.csdn.net/captain_pirate/article/details/25950545

（2）Mac和IP地址的变化：https://blog.csdn.net/xbgprogrammer/article/details/50507451 

                                      和https://blog.csdn.net/wocjj/article/details/8490397

（3）数据包传输过程的全解析：https://blog.csdn.net/u013485792/article/details/50925201

14：路由器和交换机的区别有哪些？

答：https://blog.csdn.net/xjbclz/article/details/51884359

15：四次挥手中，为什么需要有Time_Wait和Close_Wait两种状态？

TIME_WAIT状态的作用：
1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。
解决方案很简单，通过修改/etc/sysctl.conf文件，服务器能够快速回收和重用那些TIME_WAIT的资源 
ClOSE_WAIT状态作用：TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源.
什么情况下，连接处于CLOSE_WAIT状态呢？
       答案一：在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。
        答案二：出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。

16：说说关于Socket的了解？

1、套接字（socket）概念
套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应 用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
2 、建立socket连接的步骤
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发 给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
具体实例分析：
大家经常提socket，那么，到底什么是一个socket？其实，socket就是一个 五元组，包括：源IP、源端口、目的IP、目的端口、类型：TCP或者UDP；这个五元组，即标识了一条可用的连接。注意，有很多人把一个socket定义成四元组，也就是 源IP:源端口 + 目的IP:目的端口，这个定义是不正确的。
例如，如果你的本地出口IP是180.172.35.150，那么你的浏览器在连接某一个Web服务器，例如百度的时候，这条socket连接的四元组可能就是：
[180.172.35.150:45678, tcp, 180.97.33.108:80]
源IP为你的出口IP地址 180.172.35.150，源端口为随机端口 45678，目的IP为百度的某一个负载均衡服务器IP 180.97.33.108，端口为HTTP标准的80端口。
如果这个时候，你再开一个浏览器，访问百度，将会产生一条新的连接：
[180.172.35.150:43678, tcp, 180.97.33.108:80]
这条新的连接的源端口为一个新的随机端口 43678。

17：请说说对于https传输协议在客户端进行抓包，那么抓到的数据是明文还是加密的内容？

结果：抓取到的是明文
原因：
（1）加密层位于http层和tcp层之间， 所以抓到的http层的数据并没有加密。 同理， 在后台接收端， 经历解密后， 到达http层的数据也是明文。 要注意， https不是对http报文进行加密， 而是对业务数据进行加密， 然后用http传输。 
（2）https抓包的原理就是抓包程序将服务器返回的证书截获 ，然后给客户端返回一个它自己的证书；
（3）客户端发送的数据抓包程序用自己的证书解密，然后再用截获的证书加密，再发给服务器 所以你在能看到明文。
（4）密文是针对https两端以外其他路径而言，你作为https链接的两端，当然可以看到明文 。
（5）技术一点来说，TLS协议是在tcp协议之上的，tcp又是基于IP协议的。所以无论如何，你的对端IP地址是肯定无法加密的。 
（6）换个角度来看，假如你把对端ip都加密了，路由器怎么办？你的数据根本无法在网络上转发。
（7）另外TLS协议也只是把HTTP层的数据加密了，所以也只是无法看到HTTP传输的内容，但是其他协议层的内容还是明文传输的。
（1）这是因为: https(ssl)加密是发生在应用层与传输层之间，所以在传输层看到的数据才是经过加密的，而我们捕捉到的http 。
（2）post，是应用层的数据，此时还没有经过加密。这些明文信息，其实就是你的本地数据。
（3）加密数据只有客户端和服务器端才能得到明文，客户端到服务端的通信过程是安全的。

18：TCP如何实现可靠传输？

（1）确认机制
    1：TCP连接时，要进行“三次握手”
    2：应用数据被分割成TCP适合大小的数据块大小的报文段
    3：发出一个报文段，启动一个定时器，等待目的端发出确认，否则进行重传
    4：存在报文段序号和数据的校验和，启动差错检测功能
    5：存在流量控制和拥塞控制机制
    6：对失序数据可进行缓存与排序，减少不必要的冗余报文段。
    7：对于重复的报文段，可进行丢失处理。
（2）重传机制：主要是当发送超时事件和收到3个冗余ACK的情况，会重传对应序号的报文段。
（3）滑动窗口：主要是当接收方成功收到发送方的报文段，会返回一个确认号，这样就表示对应序号前面的报文段都是成功收到的，这样就可以控制发送方已发送数据未确认报文窗口的大小，从而实现流量控制，减少丢包事件的发生。
（4）拥塞控制：通过慢启动，拥塞避免，快速恢复这样的方式，来让发送方更好的适应网络情况，减少不必要的丢包。

19：Http 1.0 与 Http 1.1之间的区别有哪些？

（1）可扩展性
1：http/1.1在消息中增加版本号，用于兼容性判断
2：http/1.1增加了Options方法，它允许客户端获取一个服务器支持的方法列表。
3：为了与未来的协议规范兼容，http/1.1在请求消息中包含了upgrade头域，客户端可以让服务器知道它能够支持的其他备用通信协议，服务器可以据此进行协议切换，使用备用协议与客户端进行通信。
（2）缓存
在http/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditionale request）来判断资源是否仍有效。http/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
（3）带宽优化
http/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
http/1.1中，在请求消息中引入了rang头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部门对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206，它可以防止cache将响应误以为是完整的一个对象。
（4）长连接
http/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。
http/1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个http请求和响应，减少了建立和关闭连接的消耗和延迟。例如，一个包含有许多图像的网页文件的多个请求和应答可以再一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
http/1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接受到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
（5）消息传递
http消息中科院包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。
http/1.1中引入了Chunkedtransfer-coding来解决上面的这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。
在http/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能今夕。而http/1.1中，采用chunked分块传递的消息在最后一个块结束后再传递一个拖尾，它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值得。发送方会在消息中包含一个Traliar头域告诉接收方这个拖尾的存在。
（6）Host头域
在http1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名。但随着虚拟主机技术的发展，在一套物理服务器上可以存在多个虚拟主机，并且他们共享一个IP地址。
http1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400），此外，服务器应该接受以绝对路径标记的资源请求。
（7）错误提示
http1.0只定义了16个状态响应码，对错误或警告的提示不够具体。http1.1引入了一个warning头域，增加对错误或警告信息的描述，并且新增了24个状态响应码，如409表示请求的资源与资源的当前状态发生冲突；410表示服务器上的某个资源被永久性的删除。

20：很通俗的讲解集线器，交换机，路由器它们之间的区别？

https://mp.weixin.qq.com/s/8KU4nZYstuK_qZesljipTg

21：

    这并不是终点，而是我刚刚的开始，我会一直不断将知识点进行更新，欢迎大家进行关注和阅读！！！