计算机网络
（1）TCP、UDP区别以及用处
TCP VS UDP
- TCP 的可靠性含义： 接收方收到的数据是完整， 有序， 无差错的。
- UDP 不可靠性含义： 接收方接收到的数据可能存在部分丢失， 顺序也不一定能保证。
| TCP | UDP |
|---|---|
| 面向连接 | 无连接 |
| 提供可靠服务 | “Best effort”服务，UDP传输的数据可能会丢失，非按序到达 |
| 面向字节流，TCP把数据看成一连串无结构的字节流 | 面向报文 |
| TCP连接是一对一的：一个发送方，一个接收方 | UDP支持一对一，一对多，多对多的交互通信（广播，多播） |
| 首部开销20字节 | 首部开销8字节 |
| 全双工的可靠信道：同一连接中能传输双向数据流 | 不可靠信道传输（无确认或重传机制，没有反馈信息） |
| 常应用于流媒体应用（音视频等） | |
| 拥塞控制机制，流量控制机制 | 无拥塞控制机制 |
| 传输效率低 | 传输效率高 |
UDP：User Datagram Protocol（用户数据报协议）
-
基于Internet IP 协议
- 复用/分用
- 简单的错误校验（无错误恢复）
-
“Best effort”服务，UDP端可能（尽力而为）
- 丢失（因为无错误恢复）
- 非按序到达
-
无连接
-
UDP发送方和接收方之间不需要握手
-
每个UDP段的处理独立于其他段
-
【问题】UDP为什么存在？
- 显著减少延迟
- 实现简单：无需维护连接状态
- 头部开销少
- 没有拥塞控制： 上层应用可更好地控制发送时间和速率
TCP：Transmission Control Protocol（传输控制协议）
TCP在IP层提供的不可靠服务（不可靠的包交换）基础上实现可靠数据传输服务
-
点对点：一个发送方，一个接收方
-
可靠的，按序的字节流：重传机制，确认机制
-
流水线机制
- TCP拥塞控制和流量控制机制
- 设置窗口尺寸
-
发送方/接收方缓存 -
全双工：同一连接中能传输双向数据流
-
面向连接
- 通信双方在发送数据之前必须建立连接。
- 连接状态只在连接的两端中维护，在沿途节点中并不维护状态。
- TCP连接包括：两台主机上的缓存、连接状态变量、socket等
-
因为是可靠的，需要做的事比较多，所以传输效率低
-
客户机应用进程首先要通知客户机运输层，他想与服务器上的一个进程建立连接
-
Socket clientSocket = new Socket("hostname", portNumber);
-
【问题0】TCP连接的组成
三次握手会分配缓存和变量。
客户机进程通过socket（该进程的门户）传递数据流，数据一旦通过该门户，它就由客户机中的TCP控制了。TCP将这些数据引导到该连接的发送缓存里（发送缓存是在 TCP 3次握手时设置的）
TCP连接的组成包括
- 一台主机上的缓存（发送缓存、接收缓存）、变量（LastByteRead、RcvWindow等）和一个进程连接的套接字
- 另一台主机上的缓存、变量和一个进程连接的套接字
最大报文段长度（MSS）：报文段里面应用层数据的最大长度，而不是指包括TCP首部的TCP报文段的最大长度。
- MSS通常根据最初确定的最大链路层帧长度来设置。
- TCP报文段 = 首部字段 + 一个数据字段
- MSS限制了报文段数据字段的最大长度
【问题1】TCP的可靠数据传输，为什么？
数据包校验： 目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序： 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据： 对于重复数据，能够丢弃重复数据；
确认应答机制： 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重传机制： 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制： TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。拥塞控制：（下面）----4种解决方法
-
确认应答机制 && 序列号
-
超时重传机制 && 序列号（未收到接受法的确认ACK）
- TCP采用了连续ARQ协议（回退N，Go-back-N；超时自动重传）(自动重传请求（Automatic Repeat-reQuest，ARQ）)来保证数据传输的正确性
-
拥塞控制
-
sender限制发送速率
-
发送的最后一个bite的序号 - 最后一个确认的bite的序列号 <= 拥塞窗口大小
-
根据网络拥塞情况动态调整CongestionWindow大小----如何判断网络拥塞？
-
loss事件=timeout（发生超时）或者收到3个重复ACK
-
超时之后，发送方降低速率？
-
加性增----乘性减（AIMD）
- Increase：每个RTT增加MSS【最大段的长度】-----慢慢滴，避免拥塞
- Decrease：发生loss后将CongestionWindow减半
-
慢启动
-
当连接开始时（初始速率很慢），拥塞窗口大小呈指数增长
-
loss事件发生前拥塞窗口的一半---->改成现行增长（变量ThresHold）
thresshold: n.门槛，开始，阈
-
-
-
-
-
流量控制------让发送方的发送速率不要太快，让接收方来得及接收
- 滑动窗口机制（在连接建立时，接收方为TCP连接分配buffer，接收方会告诉发送方自己的ReceiverWindow【可接收的数据大小】）
拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。
【问题2】拥塞控制的4种方法
**1) 慢启动：**不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;
**2) 拥塞避免：**拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。加性增----乘性减（AIMD）
**3) 快重传：**快重传要求接收方在收到一个 失序的报文段后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
4) 快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，然后现行增长。但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
【问题3】TCP滑动窗口介绍
https://blog.csdn.net/yao5hed/article/details/81046945
滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。
滑动窗口解决的是流量控制的的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。接收端的缓存传输数据给应用层，但这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。
TCP使用滑动窗口做流量控制与乱序重排
- 保证TCP的可靠性
- 保证TCP的流控特性
滑动机制
发送方没有收到接收方发回的ACK，就不能向右滑动。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
（2）HTTP和HTTPS的区别
Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：
端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种对称加密和和公开密钥加密并用的混合加密机制。
（3）对称加密和非对称加密
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。
非对称加密 的密码对生成和加密的消耗时间比较长，为了节省双方的计算时间，通常只用它来交换密钥，而非直接用来传输数据。
【问题1】Https怎么保证安全
通过 对称加密 + 非对称加密 + CA认证 这三个技术混合在一起，才使得 HTTP 的后面加上了一个 S —— Security
服务器用明文的方式给客户端发送自己的公钥（有证书），客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。
CA(认证中心) 是一些非常权威的专门用于认证一个网站合法性的组织。服务商可以向他们申请一个证书，使得他们建立安全连接时可以带上 CA 的签名。而 CA 的安全性由操作系统或浏览器来认证。你的 Windows、Mac、Linux、Chrome、Safari 等会在安装时带上一个他们认为安全的 CA 证书列表。如果和你建立安全连接的人带着这些人的签名，那么认为这个安全连接是安全的，没有遭到中间人攻击。
非对称加密会不安全，是因为客户端不知道这把公钥是否是服务器的，因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。解决这个问题的方式就是使用数字证书，具体是这样的：
我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。
简书：https://www.jianshu.com/p/b894a7e1c779
https://www.cnblogs.com/kubidemanong/p/9390021.html
【问题2】 https数据传输加密过程—important
① 证书验证阶段：
1）浏览器发起 HTTPS 请求；
2）服务端返回 HTTPS 证书（包含服务端的公钥）；
3）客户端验证证书是否合法，如果不合法则提示警告。
② 数据传输阶段：
1）当证书验证合法后，在本地生成对称密钥；
2）客户端通过公钥加密对称密钥，并把加密后的对称密钥传输到服务端；
3）服务端通过私钥进行解密，获得（已用公钥加密过的）对称密钥；
4）这样可以在确保交换的密钥安全的前提下，使用对称加密方式进行通信。
（4） TCP三次握手和四次挥手
1、三次握手
(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)
第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。（该报文段不包含应用层数据）
**第二次握手：**Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态
- 服务器会从数据报中提取TCP SYN报文段，为该TCP连接分配缓存和变量
- 在三次握手的第三部之前分配这些缓存和变量，使得TCP易于受到称为SYN洪泛的拒绝服务攻击
- 这个允许连接的报文也不包含应用层数据
**第三次握手：**Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
- 在受到SYN ACK报文段之后，客户机也要给该连接分配缓存和变量
- 因为连接已经建立，所以SYN比特被置为0
【问题1】SYN泛洪攻击
服务器为了相应一个收到的SYN，分配并初始化连接变量和缓存。然后服务器发送一个SYN ACK进行响应，并等待来自客户机的ACK报文段。如果客户机不发送ACK来完成第三次握手的第三步，最终（通常在一分钟之后）服务器将终止该半开连接并回收已分配的资源。
解决方法：
SYN cookies
2、 四次挥手
当连接结束后，主机使用的资源（缓存和变量）将被释放
(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。客户端收到ACK报文之后进入FIN_WAIT_2状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。（客户端收到“确认包”后进入FIN_WAIT_2状态，等待服务器准备完毕后再次发送数据包。）
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
注意：计算机收到服务器的确认之后，启动2MSL定时器，在time_wait状态还需再等2MSL，才会close。防止第四步的确认数据包丢失，万一确认服务器没有收到，服务器再发送FIN时，客户端还能给服务器确认。
【状态迁移过程：】
**客户端：**CLOSED --> SYN_SENT --> ESTABLISHED --> FIN_WAIT_1 --> FIN_WAIT_2 --> TIME_WAIT --> CLOSED
**服务端：**CLOSED --> LISTEN --> SYN_RECEIVED --> ESTABLISHED --> CLOSE_WAIT --> LAST_ACK --> CLOSED
TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。
acknowledgement number 的作用是向对方表示，我期待收到的下一个序号。 如果你向对方回复了 ack = 31, 代表着你已经收到了序号截止到30的数据，期待的下一个数据起点是 31 。
TCP 协议规定SYN报文虽然不携带数据，但是也要消耗1个序列号，所以前两次握手客户端和服务端都需要向对方回复 x+1 或 y+1 。
**序列号seq：**占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。
**确认号ack：**占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。
**确认ACK：**占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
**终止FIN：**用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接
【问题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】TCP 为什么三次握手而不是两次握手（正解版）
-
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
-
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
【问题3】为什么不能用两次握手进行连接？
答：为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。
客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。
【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
（5）OSI七层模型，五层参考模型，TCP/IP参考模型
当前存在三种划分网络模型的方式：
-
OSI 7层，
-
TCP/IP 4层
-
五层参考模型，综合 OSI 和 TCP/IP 的优点
TCP/IP四层模型跟OSI模型有什么不一样？
OSI是一个完整的、完善的宏观理论模型；而TCP/IP(参考)模型，更加侧重的是互联网通信核心(也是就是围绕TCP/IP协议展开的一系列通信协议)的分层，因此它不包括物理层，以及其他一些不相干的协议；其次，之所以说他是参考模型，是因为他本身也是OSI模型中的一部分，因此参考OSI模型对其分层。
五层模型：五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层。五层协议只是OSI和TCP/IP的综合，实际应用还是TCP/IP的四层结构。
【问题1】为什么现在五层参考模型说的比较多一些？
五层参考模型，综合 OSI 和 TCP/IP 的优点 ？？？？
所谓的五层协议的网络体系结构其实是为了方便学习计算机网络原理而采用的，综合了OSI七层模型和TCP/IP的四层模型而得到的五层模型。
【问题2】各个层次之间常用的协议
应用层：负责处理应用程序的逻辑
传输层：为两个主机上的应用程序提供端到端的通信
网络层：主要是控制数据报的选路和转发
数据链路层：物理寻址，同时将原始比特流转变为逻辑传输线路
- 应用层： HTTP， TelNet， FTP， SMTP， DNS
应用层负责处理应用程序的逻辑。数据链路层，网络层和传输层负责处理网络通信细节，这部分必须稳定又高效，因为它们是在内核空间中实现的。但是应用层则是在用户空间实现，因为它负责处理众多逻辑，如文件传输，网络管理等。
-
HTTP协议：超文本传输协议，本质上是一种通信协议。HTTP定义了web客户机如何向服务器请求web页面，以及服务器如何将web页面传送给客户机。Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份
-
FTP协议：文件传输协议。
- 也运行在TCP之上
- FTP使用两个并行的TCP连接来传输文件
- 一个是控制连接 control Connection：用于在两个主机之间传输控制信息，如用户标识、口令、改变远程的命令以及“PUT”和“GET”文件的命令（持久性连接）
- 一个是数据连接 Data Connection：用于实际传输一个文件（非持久性连接）
- 对FTP传输而言，控制连接贯穿整个用户会话期间，但是针对会话中的每一次文件传输都需要建立一个新的数据连接
-
DNS协议：DNS协议运行在UDP之上，使用53号端口。
DNS协议通常被其他应用层协议（HTTP、SMTP、FTP）所使用。DNS提供的服务：
-
域名到IP地址的转换 （标识主机的方法：1.主机名（域名） ； 2.IP地址）
- 因为IP地址是固定长度的，IPv4是32位，IPv6是128位，而域名是变长的，不便于计算机处理。
- IP地址对于用户来说不方便记忆，但域名便于用户使用，例如www.baidu.com这是百度的域名。
- 总结：IP地址是面向主机的，而域名则是面向用户的。
-
域名解析过程：
- 主机先向本地域名服务器进行递归查询
- 本地域名服务器采用迭代查询，向一个根域名服务器进行查询
- 根域名服务器告诉本地域名服务器，下一次应该查询的顶级域名服务器的IP地址
- 本地域名服务器向顶级域名服务器进行查询
- 顶级域名服务器告诉本地域名服务器，下一步应该查询的权威域名服务器的IP地址
- 本地域名服务器向权威域名服务器进行查询
- 权威域名服务器告诉本地域名服务器所查询的主机的IP地址
- 本地域名服务器最后把查询结果告诉主机
3类型的DNS服务器：
- 根DNS服务器
- 顶级域DNS服务器（Top-Level Domain， TLD）
- 权威DNS服务器
本地DNS服务器
-
- 传输层：TCP，UDP （开篇的那张表）
它为两台主机上的应用程序提供端到端的通信。传输层只关心通信的起始端和目的端，而不在乎数据包的中转过程。
- TCP协议：传输控制协议，位应用层提供可靠的、面向连接的流式服务
- UDP协议：用户数据报协议、它与数据TCP协议完全相反，它为应用层提供不可靠、无连接的数据报服务。
- 网络层：IP，ICMP，RIP，IGMP
实现数据包的选路和转发。网络层最核心的协议就是IP协议（因特网协议），IP协议根据数据包的目的IP地址来决定如何投递它。另一个重要的协议是ICMP协议（因特网控制报文协议）。它是IP协议的重要补充，主要用于监测网络链接。
- 数据链路层：**ARP协议（地址解析协议）**和RARP协议（逆地址解析）之间的互换。
物理寻址，同时将原始比特流转变为逻辑传输线路。
**定义了如何让格式化数据以进行传输，以及如何控制对物理介质的访问。**这一层通常还提供错误检测和纠正，以确保数据的可靠传输。实现了网卡端口的网络驱动程序，以处理数据在物理媒介（如以太网）上的传输。
（6）Http1.1和Http1.0的区别
非持久性连接(NonpersistentHTTP)
每个TCP连接最多允许传输一个对象
HTTP 1.0版本使用非持久性连接
持久性连接(Persistent HTTP)
每个TCP连接允许传输多个对象
HTTP 1.1版本默认使用持久性连接
HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写
1、长连接
-
HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。
-
HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求。
2、节约带宽
-
HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。
-
HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器；如果接收到401，客户端就可以不用发送请求body，节约了带宽。
另外HTTP1.1还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。
3、 HOST域
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
4、缓存处理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
5、错误通知的管理
在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
（7）HTTP1.1和HTTP2.0的区别
1、多路复用
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。
HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
2、头部数据压缩
HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。
3、服务器推送
为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
（8）为什么要用http而不是直接用tcp这些底层的协议
一句话概括：HTTP连接 = 以HTTP协议为通信协议的TCP连接
Http 是 TCP的上层协议，Http 是基于 TCP的，所以你用了HTTP，等同与你也在用TCP
-
TCP/IP协议可以两个进程通过三次握手建立稳定的通信信道，发送字节流；而HTTP协议建立在TCP/IP协议之上，也就是说TCP/IP协议可以让两个程序说话，而HTTP协议定义了说话的规则。
-
我们在传输数据时，可以只使用TCP/IP协议进行传输，但是这样没有应用层的参与，会导致两端无法识别数据内容，这样传输的数据也就没有意义了。因此如果想让传输的数据有意义，那么就必须要用到应用层的协议(HTTP、FTP、TELNET等)，也可以自己定义应用层的协议。
-
WEB使用HTTP协议作为应用层的协议，以封装HTTP文本信息，然后使用TCP/IP作为传输层的协议将它发到网络上。
Socket: 套接字
Socket API :应用进程间通信的抽象机制
标识通信端号（对外）
- IP地址 + 端口号
操作系统/继承如何管理套接字（对内）
- 套接字描述符（socket descriptor）
- 小整数
（9）Http常见的状态码
HTTP状态码（英语：HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。
HTTP状态码分类
HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。
HTTP状态码共分为5种类型：
-
1** 请求处理中，请求已被接受，正在处理
-
2** 成功，请求被成功接收并处理。200 ：OK
-
3** 重定向，客户端需要做些额外工作才能得到所需要的资源。301 : 永久性转移 | 302 ：暂时性转移 | 304 ： 已缓存
-
4** 客户端错误，请求包含语法错误或无法完成请求。
400：Bad Request,请求有语法问题 | 403：拒绝请求 | 404：客户端所访问的页面不存在
-
5** 服务器错误，服务器不能处理合法请求。
500 ：服务器内部错误 | 503 ： 服务不可用，稍等
（10）Http request的8种类型
1、 OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*’的请求来测试服务器的功能性。
2、HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
3、**GET：**向特定的资源发出请求。
4、**POST：**向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
5、PUT：向指定资源位置上传其最新内容。
6、DELETE：请求服务器删除Request-URI所标识的资源。
7、TRACE：回显服务器收到的请求，主要用于测试或诊断。
8、CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
（11）在浏览器中输入URL地址，到显示主页的过程
分为以下六个过程：
- DNS解析：网址到IP地址的转换。
- TCP连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；
- 发送HTTP请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；
- 服务器处理请求并返回HTTP报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
- **浏览器解析渲染页面：**浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
- 连接结束
每个阶段用到的协议：
DNS协议：获取域名对应IP
TCP协议：与服务器建立TCP连接
IP协议：建立TCP协议时需要发送数据，发送数据在网络层使用IP协议
OPSF:IP数据包在路由器之间，路由选择使用OSPF协议
ARP协议：路由器在与服务器通信时，需将IP地址转换为MAC地址，需使用ARP
HTTP协议：在TCP建立完成之后，使用HTTP协议访问页面
（12）网络字节序 VS 本地字节序
网络字节序：一般是指采用大端法存储网络地址
本地主机字节序：一般是指采用小端法存储本地主机地址
字节序定义：是指整数在内存中保存的顺序。
**大端法：**低字节保存在内存的高位，高字节保存在内存的低位
**小端法：**低字节保存在内存的低位，高字节保存在内存的高位
什么是网络字节序，为什么可以保证在传输时能够被正确解释？
网络字节顺序是TCP/IP中规定好的一种数据表示格式，它与具体的CPU类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解释。
（13）cookie和session
一、共同之处：
cookie和session都是用来跟踪浏览器用户身份的会话方式。
二、工作原理：
1.Cookie的工作原理
（1）浏览器端第一次发送请求到服务器端
（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
（3）浏览器收到响应后，生成cookie信息。当浏览器端再次访问服务器端时会携带服务器端创建的Cookie
（4）服务器端通过Cookie中携带的数据区分不同的用户
2.Session的工作原理
（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端
（2）浏览器端发送第N（N>1）次请求到服务器端，浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
（3）服务器端根据name为JSESSIONID的Cookie的value(sessionId)，去查询Session对象，从而区分不同用户。
-
name为JSESSIONID的Cookie不存在（关闭或更换浏览器），返回1中重新去创建Session与特殊的Cookie
-
name为JSESSIONID的Cookie存在，根据value中的SessionId去寻找session对象
-
value为SessionId不存在**（Session对象默认存活30分钟）**，返回1中重新去创建Session与特殊的Cookie
-
value为SessionId存在，返回session对象
Session的工作原理图
三、区别对比：
-
cookie数据存放在客户的浏览器上，session数据放在服务器上（存放地址不同）
-
session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
-
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，如果主要考虑到安全应当使用session
-
cookie 可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量
-
所以：将登陆信息等重要信息存放为SESSION；其他信息如果需要保留，可以放在COOKIE中
四、缺点
1. 使用cookie的缺点
-
如果浏览器使用的是cookie，那么所有的数据都保存在浏览器端，
-
cookie可以被用户禁止
-
cookie不安全(对于敏感数据，需要加密)
- 如果你能够截获某个用户的cookie变量，然后伪造一个数据包发送过去，那么服务器还是 认为你是合法的。所以，使用cookie被攻击的可能性比较大。
-
cookie只能保存少量的数据(大约是4k)，cookie的数量也有限制(大约是几百个)，不同浏览器设置不一样，反正都不多
-
cookie只能保存字符串
对服务器压力小
2.使用session的缺点
-
一般是寄生在Cookie下的，当Cookie被禁止，Session也被禁止
- 当然可以通过url重写来摆脱cookie
-
当用户访问量很大时，对服务器压力大
- 我们现在知道session是将用户信息储存在服务器上面，如果访问服务器的用户越来越多，那么服务器上面的session也越来越多，session会对服务器造成压力，影响服务器的负载。如果Session内容过于复杂，当大量客户访问服务器时还可能会导致内存溢出。
用户信息丢失， 或者说用户访问的不是这台服务器的情况下，就会出现数据库丢失
（14）Socket
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。TCP连接则更依靠于底层的IP协议，IP协议的连接则依赖于链路层等更低层次。
Socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作.
Socket即是 一种特殊的文件 一些Socket函数就是对其进行的操作（读/写IO、打开、关闭）.
- 服务端调用socket（）方法创建一个socket。创建一个socket描述符（socket descriptor），它 唯一标识一个socket 。
- 服务端调用bind（）方法绑定socket和端口号，并调用由listen（）方法监听该端口号。
- TCP客户端调用socket（）方法创建socket，并调用connect（）方法了解指定计算机的端口，向TCP服务器发送一个连接请求
- TCP服务器监听到这个请求之后，就会调用
accept()函数取接收请求，这样连接就建立好了 - 当服务器与客户端建立好了TCP连接，可以调用网络I/O进行读写操作。即实现网络中不同进程间的通信.
- read() / write()
- recv() / send()
- 当完成读写操作之后就要关闭相应的socket描述字，调用close（）方法（好比打开的文件要调用fclose关闭打开的文件）
- close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求
ket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作.
Socket即是 一种特殊的文件 一些Socket函数就是对其进行的操作（读/写IO、打开、关闭）.
[外链图片转存中…(img-d12v83vT-1628430902114)]
- 服务端调用socket（）方法创建一个socket。创建一个socket描述符（socket descriptor），它 唯一标识一个socket 。
- 服务端调用bind（）方法绑定socket和端口号，并调用由listen（）方法监听该端口号。
- TCP客户端调用socket（）方法创建socket，并调用connect（）方法了解指定计算机的端口，向TCP服务器发送一个连接请求
- TCP服务器监听到这个请求之后，就会调用
accept()函数取接收请求，这样连接就建立好了 - 当服务器与客户端建立好了TCP连接，可以调用网络I/O进行读写操作。即实现网络中不同进程间的通信.
- read() / write()
- recv() / send()
- 当完成读写操作之后就要关闭相应的socket描述字，调用close（）方法（好比打开的文件要调用fclose关闭打开的文件）
- close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求
499
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
