计算机网络快速入门

前言

由于当初没有好好学计网, 现在迫于面试的压力, 来复习了

2021-4-13 17:32:37

网络层次划分:

这里主要就是三种模型

在理解了下头的OSI七层模型之后, 上头的这个就不是问题了

OSI七层网络模型:

七层网络模型这里比较难理解

推荐参考的网站

简单理解

https://www.zhihu.com/question/24002080/answer/31817536

具体理解:

https://blog.csdn.net/yaopeng_2005/article/details/7064869

https://www.cnblogs.com/qishui/p/5428938.html

应用层:

主要承载的是应用软件使用的协议, 如http, SMTP, DHCP, DNS 等, 这些协议规定了软件如何去通信

表示层

表示层决定应用层数据的展现形式, 为上层数据提供各种编码与转换功能, 确保一个系统的应用层数据能够被另一系统的应用层所识别

会话层

会话层主要与会话相关, 其负责建立, 管理和重视表示层实体之间的通信会话

同时还包括认证鉴权 & 检查点记录 (功能类似于断点续传)

传输层

起到承上启下的作用

主要的设备是网关

将一个数据拆分成多个小段, 标记顺序以便于接收端重组, 标记该应用程序使用的端口号 & QOS

网络层

传输层是最重要也是最复杂的一层

主要是路由器所在的层, 所以当然是路由器干的活

包括IP协议, 路径选择、路由及逻辑寻址

此层也成为ip协议层

数据链路层

数据链路层是交换机所在的层(二层交换机), 使用MAC进行传输地址的确认, 而网络层使用的是逻辑地址IP来确认传输的目标地址

具体是: 根据MAC地址, 做分组隔离, 端口安全, 访问控制

通过各种控制协议, 将不可靠的物理链路转换为可靠的数据链路

注意的是, 数据链路层(交换机)只能根据MAC将数据转发到所在的子网当中, 如果需要转发到其他子网, 则必然要通过路由器, 即需要上升到网络层

物理层

保证比特流透明的传输

透明指的是经过物理层传输的的比特流前后没有变化, 对于传送的比特流而言, 物理层是不可见的

TCP

Transmission Control Protocol 传输控制协议

参考博客:

https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc

三次握手:

握手之前客户端&服务器都退出各自的CLOSED阶段, 服务器进入LISTEN状态

1. 首先客户端想服务器发送一段TCP报文, 其中:

   置SYN=1, seq=x 表示请求建立新连接

   随后进入SYN-SENT阶段

2. 服务器收到来自客户端的TCP报文后, 结束LISTEN阶段,并返回一段报文, 其中:

   置SYN=1, ACK=1, 表示确认客户端的报文Seq有效, 服务器能正常接收客户端发送的数据, 并同意创建连接

   置seq=y, 确认号Ack=x+1, 表示受到客户端的Seq并将其+1作为自身的ack值

   随后服务器进入SYN-RCVD阶段

3. 客户端收到来自服务器的确认TCP报文之后, 结束SYN-SENT阶段, 并返回最后一段报文, 其中:

   置ACK=1, 表示确认受到服务器的同意连接信号

   置Seq=x+1, 表示确认受到服务器端的确认号Ack, 并将其作为自身的序号值

   置Ack=y+1, 表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值

   随后进入ESTABLISHED阶段

4. 服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段

三次握手的过程中, 双方的Ack & Seq都是对方的Ack & Seq基础上进行计算的, 确保了TCP报文传输的连贯性

这样一旦一方发出的TCP报文丢失, 则无法继续握手, 以此确保了三次握手的顺利完成

为何握手是三次:

1. 为了防止服务器端开启一些无用的连接增加服务器开销
2. 防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误

因为如果在三次握手中的第一个数据包被服务器接收到, 而服务器发出的第二个数据包在传输过程中丢失了, 客户端就会因为没收到这个数据包而发起第二次连接, 此时如果服务器受到了客户端的第二个连接, 则会再次创建一个新的TCP连接, 此时之前的连接就会一直开着, 造成了服务端的资源浪费

另一种情况是, 已经失效的客户端发送的请求报文, 被服务器接收到了, 务器端以为是客户端发出的有效请求，接收后产生错误

所以需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待

四次挥手:

1. 首先客户端退出ESTABLISHED状态, 并向服务器发送一段TCP报文, 其中

   置FIN=1, 表示请求释放连接

   并置seq=u

   随后进入FIN-WAIT-1半关闭阶段, 并停止向服务器发送数据, 但此时仍然能收到服务器的数据

2. 服务器收到客户端的TCP报文后, 确认客户端将要释放连接, 随后服务器也结束ESTABLISHED状态, 进入CLOSE-WAIT状态, 并返回一个TCP报文, 其中:

   置ACK=1, 表示接受到客户端发送的释放连接请求

   置Seq=v, Ack=u+1, 表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值

   后服务器端准备释放服务器端到客户端方向上的连接, 进入CLOSED-WAIT状态

3. 客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

4. 服务器进入CLOSED-WAIT状态后, 在向客户端发送一段TCP报文

   置FIN=1, ACK=1, 表示已经准备好释放连接

   置Seq=w, ack=u+1, 表示是在收到客户端报文的基础上, 将其序号Seq值加1作为本段报文确认号Ack的值

   随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段, 并且停止在服务器端到客户端的方向上发送数据, 但仍能接受客户端的数据

5. 客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

   置ACK=1, 表示接收到服务器准备好释放连接的信号

   置Seq=u+1, 表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值

   置确认号Ack=+1, 表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值

   随后客户端开始在TIME-WAIT阶段等待2MSL后, 进入CLOSED状态

6. 服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段, 由此正式确认关闭服务器端到客户端方向上的连接

与三次挥手相同, 四次挥手中, 双方的确认号Ack和序号Seq的值也是在彼此的基础上进行计算的, 保证了TCP报文传输的连贯性, 一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成

为何握手三次而挥手四次:

因为在三次握手的过程中, 第二次握手中, 服务器发送的TCP报文将SYN建立连接报文与ACK确认报文同时发送, 所以三次握手不多不少, 正好让双方能确认彼此信息互通

而四次挥手, 是因为FIN释放连接报文与ACK确认接收报文是分别在第二次和第三次挥手传输的, 所以需要4次

拓展: 为何建立连接时一起传输, 而释放时却分开传输

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接

而释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文

---

挥手结束后为何要进行2MSL的等待:

为的是确认服务器端是否收到客户端发出的ACK确认报文

由于客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文, 所以设置了一个2MSL(Maximum Segment Lifetime)超时计时器, 当服务器在1MSL内没收到客户端发出的ACK报文时, 就会再次向客户端发送FIN报文, 此时如果客户端在2MSL内再次受到了来自服务器的FIN报文, 则再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时, 否则视为服务器正常收到报文, 进入CLOSED状态

---

传输可靠性:

参考博客:

https://blog.csdn.net/liuchenxia8/article/details/80428157

TCP协议保证数据传输可靠性的方式主要有：

• 校验和
• 序列号
• 确认应答
• 超时重传
• 连接管理
• 流量控制
• 拥塞控制

校验和:

将发送过程中的每个数据段相加, 并将进位补在后头, 最后取反, 得到校验和

发送方计算校验和, 并连同数据一并发送

接收方接收数据后, 重新计算校验和是否符合要求, 如果有误, 则舍弃数据

确认应答与序列号

1. 序列号:

   TCP在传输过程中, 每个字节的数据都进行了编号, 称之为序列号

   序列号用于将传输的数据重新拼成完整的序列

2. 确认应答

   每次接收方收到数据后, 都会向数据发送端进行确认应答, 即发送一个ACK报文

   此报文中带有对应的确认序列号, 用于告诉发送方, 接收了哪些数据, 下一次的数据从哪开始发

   

超时重传:

上头说道了确认应答机制

当发送方在限定时间内没有收到应答方的ACK报文时, 发送方会重新发送之前的数据

这解决了两种情况:

1. 发送的数据确实没有到达接收方
   接收方重新受到发送方的数据, 并回送ACK
2. 接收方收到了数据, 但是ACK报文丢失
   接收方确认了接收到的数据与之前相同, 直接丢弃, 但仍然回送ACK

超时时间的计算:

超时时间在超时重传机制中是非常重要的, 所以Linux系统中采用的是倍增法动态计算, 初始500ms, 每次超时后的等待时间为之前的两倍

连接管理:

连接管理就是三次握手, 四次挥手的过程

这里不再赘述

流量控制

流量控制主要是为了发送端&接收端的速度同步

在发送端速度快于接收端的情况下, 数据会在接收端处大量堆积, 当缓冲区满了之后, 就会导致后续的数据大量丢包, 进而导致一系列的连锁反应, 所以需要流量控制

流量控制的实现通过TCP报头, 在TCP报头信息中有一个16位字段的窗口, 其实际存储的就是接收端数据缓冲区的剩余大小, 而发送端就通过读取接收端ACK报文中的缓冲区大小来判断接收端的数据接收能力

如果接收到窗口大小为0, 则发送方将停止发送数据, 并定期的向接收端发送窗口探测数据段, 来检测接收端是否恢复数据接收能力

拥塞控制:

参考博客:

https://blog.csdn.net/qq_41431406/article/details/97926927

上头提到了TCP传输过程中的速度不匹配问题

而大量发送的数据还可能导致另一个问题, 网络拥塞

如果一开始就发送大量的数据, 网络可能在开始时就会很拥堵, 此时会发生类似上头的丢包&超时重传问题, 严重影响传输

为了解决拥塞, TCP使用了以下几个机制:

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复

这里具体部分直接去看博客了:

https://blog.csdn.net/qq_41431406/article/details/97926927

面试题:

TCP的拥塞控制机制是什么？请简单说说。

答：TCP通过一个定时器（timer）采样了RTT并计算RTO，但是，如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，然而重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成“网络风暴” —— TCP的拥塞控制机制就是用于应对这种情况

首先需要了解一个流量控制的概念，为了在发送端调节所要发送的数据量，定义了一个“拥塞窗口”（Congestion Window），在发送数据时，将拥塞窗口的大小与接收端ack的窗口大小做比较，取较小者作为发送数据量的上限

拥塞控制主要是四个算法：

1. 慢启动：即刚刚建立的TCP连接，速度并非一开始就占满, 而是缓慢提速

   以下是详细部分, 讲的话如果被深挖, 则详细部分不详

   连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。
   每当收到一个ACK，cwnd++; 呈线性上升
   每当过了一个RTT，cwnd = cwnd*2; 呈指数让升
   阈值ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”

2. 拥塞避免：当拥塞窗口 cwnd 达到一个阈值时，窗口大小不再呈指数上升，而是以线性上升，避免增长过快导致网络拥塞

   以下是详细部分, 讲的话如果被深挖, 则详细部分不详

   每当收到一个ACK，cwnd = cwnd + 1/cwnd
   每当过了一个RTT，cwnd = cwnd + 1
   拥塞发生：当发生丢包进行数据包重传时，表示网络已经拥塞。分两种情况进行处理：
   等到RTO超时，重传数据包
   sshthresh = cwnd /2
   cwnd 重置为 1

3. 快重传:

   以下是详细部分, 讲的话如果被深挖, 则详细部分不详

   快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期

4. 快速恢复：此方法通常配合快重传使用

   当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法, 而 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法

   以下是详细部分, 讲的话如果被深挖, 则详细部分不详

   cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了）
   重传Duplicated ACKs指定的数据包
   如果再收到 duplicated Acks，那么cwnd = cwnd +1
   如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。

UDP

User Datagram Protocol 用户数据报协议

面向无连接的通讯协议

数据包括目的端口号 & 源端口号信息, 但不需要连接, 所以可以实现广播发送

其不管数据包的顺序、错误或重发, 通讯时不需要接收方确认，属于不可靠的传输

详细学习看这里:

https://blog.csdn.net/aa1928992772/article/details/85240358

不能控制读写数据的次数和数量

常用一次性传输比较少量数据的网络应用 与 高实时性的应用

传输可靠性:

参考博客:

https://blog.csdn.net/pangyemeng/article/details/50387078

由于UDP的无连接特性, UDP的传输层不负责保证传输可靠性, 需要靠应用层实现

其实现的方式可以参考TCP, 如实现确认机制、重传机制、窗口确认机制等

如果直接使用更底层的抓包与发包的形式去实现的话, 就必须实现一下功能:

• 发送：包的分片、包确认、包的重发
• 接收：包的调序、包的序号确认

TCP & UDP 的比较:

DNS

将域名转换为IP, 与ARP异曲同工

域名解析过程仍会优先是用本地hosts文件, 而后才是查找DNS服务器

域名

DNS的附加知识点

域名使用层次结构命名的方式, 使用.来区分层级:

被.分割开的称为标号, 有几个要求:

1. 标号由字母（A-Z，a-z，大小写等价）、数字（0-9）和连接符（-）组成
2. 标号序列总长度不能超过255个字符
3. 每个标号应该在63个字符之内
4. 低级别域名在左, 高级别在右

域名解析过程:

1. 输入域名后, 先查找自己主机对应的域名服务器，域名服务器先查找自己的数据库中的数据.
2. 如果没有， 就向上级域名服务器进行查找， 依次类推
3. 最多回溯到根域名服务器, 肯定能找到这个域名的IP地址
4. 域名服务器自身也会进行一些缓存， 把曾经访问过的域名和对应的IP地址缓存起来, 可以加速查找过程

具体过程表述如下:

1. 主机先向本地域名服务器进行递归查询
2. 本地域名服务器采用迭代查询，向一个根域名服务器进行查询
3. 根域名服务器告诉本地域名服务器，下一次应该查询的顶级域名服务器的IP地址
4. 本地域名服务器向顶级域名服务器进行查询
5. 顶级域名服务器告诉本地域名服务器，下一步查询权限服务器的IP地址
6. 本地域名服务器向权限服务器进行查询
7. 权限服务器告诉本地域名服务器所查询的主机的IP地址
8. 本地域名服务器最后把查询结果告诉主机

其中:

1. 递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机
2. 迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询

二者就是递归与循环的区别

NAT

network address translation

这个在路由搭建的时候有用到
内网地址在过防火墙的时候会经过NAT转换为外网地址, 所以如果关闭了防火墙, 也就没网了

NAT 可以让那些使用私有地址的内部网络连接到Internet或其它IP网络上。NAT路由器在将内部网络的数据包发送到公用网络时，在IP包的报头把私有地址转换成合法的IP地址

之前谈到了3块私有地址:

• A类：10.0.0.0—10.255.255.255 10.0.0.0/8
• B类：172.16.0.0—172.31.255.255 172.16.0.0/12
• C类：192.168.0.0—192.168.255.255 192.168.0.0/16

这三块地址本身可路由, 但是公网上的路由器不会转发这三块私有地址的流量, 而NAT技术就是将私有IP转换为外网IP

三种不同的NAT

1. 静态NAT

   一对一

   与静态路由相似, NAT映射表是写死的, 一条内网IP固定映射到一个外网IP

2. 动态地址NAT

   多对多

   这玩意类似于DHCP的动态分配

   当内网IP发起通信请求时, 从外网IP池中动态申请一个对应的外网IP并与内网IP绑定, 通信结束后则释放

3. 网络地址端口转换 NAPT

   Network Address Port Translation

   多对一

   采用多路复用的形式, 内部网络的所有IP都可共享一个合法的外部IP, 最大程度的节省IP资源, 其使用同一个外部地址的不同端口来区分内部地址

   所以也是现在常用的NAT技术

DHCP

Dynamic Host Configuration Protocol

使用UDP工作, 目的端口67

DHCP交互:

1. Client端在局域网内发起一个DHCP　Discover包，目的是想发现能够给它提供IP的DHCP Server
2. 可用的DHCP Server接收到Discover包之后，通过发送DHCP Offer包给予Client端应答，意在告诉Client端它可以提供IP地址
3. Client端接收到Offer包之后，发送DHCP Request包请求分配IP
4. DHCP Server发送ACK数据包，确认信息

DHCP包分析:

直接看教程:

https://blog.csdn.net/u012359618/article/details/51872678

HTTP

参考教程:

https://www.cnblogs.com/an-wen/p/11180076.html

http的几个特点:

1. 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
2. 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
3. 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
4. 简单快速、灵活
5. 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

http请求/响应的步骤:

1. DNS域名解析

   首先浏览器会对域名进行解析, 找到对应的IP地址

2. 建立TCP连接

   在获取到IP地址后, 客户端浏览器会以一个随机端口, 向服务器的80端口发起TCP连接请求, 通过三次握手, 建立TCP连接

3. 建立TCP连接后发起HTTP请求

   通常浏览器使用HTTP的get方法, 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文, 请求Web服务器上相应的目录资源

4. 服务器收到HTTP请求并响应, 向客户端返回HTML代码

   Web服务器解析请求，定位请求资源, 并将资源副本写入到TCP套接字中, 供客户端读取, 通常是返回index.html

5. 浏览器获取到index.html后, 解析HTML代码

   遇到js/css等静态资源时, 就向服务器请求下载, 通常利用keep-alive的特性, 以多线程的形式进行请求,

6. 之后, 浏览器对根据HTML语法对页面进行渲染, 并呈现给用户

老版本, 回答的不是很完整

1. 客户端连接到Web服务器
   一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.baidu.com
2. 发送HTTP请求
   通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成
3. 服务器接受请求并返回HTTP响应
   Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成
4. 释放连接TCP连接
   若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求
5. 客户端浏览器解析HTML内容
   客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示

8种请求方式:

1. OPTIONS

   返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性

2. HEAD

   向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。

3. GET

   向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url

4. POST

   向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form

5. PUT

   向指定资源位置上传其最新内容

6. DELETE

   请求服务器删除Request-URL所标识的资源

7. TRACE

   回显服务器收到的请求，主要用于测试或诊断

8. CONNECT

   HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

注意:

1. HTTP服务器至少应该实现GET和HEAD/POST方法, 而其他方法都是可选的
2. 方法名称是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Mothod Not Allowed）；当服务器不认识或者不支持对应的请求方法时，应返回状态码501（Not Implemented）

响应报文的头部信息:

Session & Cookies & Application

Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案

Cookies

参考博客:

https://www.cnblogs.com/fly_dragon/p/9186730.html

Cookies是服务器发送到浏览器并保存在本地的一小块文本数据, 其会在浏览器下一次向同一个服务器访问时, 加入到HTTP head中被一并发送, 弥补了HTTP无状态的缺陷

Cookie 常用于以下几个方面：

• 购物车（网购）
• 自动登录（登录账号时的自动登录）
• 精准广告
• 平常浏览网页时有时会推出商品刚好是你最近浏览过，买过的类似东西，这些是通过 cookie 记录的。
• 记住登录状态

Cookies的构成:

1. Name 名称

   唯一用来确定Cookies的名称, 不区分大小写

   Cookies的名称必须是经过URL编码的, 注意要确保名称唯一

2. Value 值:

   存储在 cookie 中的字符串值，必须经过被 URL 编码

3. Domain 域

   指定Cookies所属于的域, 决定了那些Web服务器可以读取本地存储的Cookies

   如果创建Cookies时缺省, 则默认将使用Web服务器的域名

4. Path

   决定了web服务器上的哪些路径下的页面可以获取服务器设置的Cookies

   通常Path是用户输入的第一个字符开始

5. Expires 失效时间

   表示Cookies何时应该被删除的时间戳, 使用GMT格式

   超过时间的Cookies会被立刻删除

6. Secure 安全标志

   如果此变量被标记, 则表明只有当客户端与服务器使用加密协议通讯时, 才会使用此Cookies

Cookies的相关限制

1. 部分浏览器对Cookies的数量会有一定限制

   但Safari & Chrome没有硬性规定

2. 每个domain最多只能有20条Cookies

3. Cookies会随着Http发送到服务器, 增加了额外的流量

Session:

参考博客

https://www.cnblogs.com/sharpxiajun/p/3395607.html

与Cookies相比, Session属于的服务端, 而后者属于客户端

Session这里要翻译为会话, 客户端与服务器之间的一些列交互动作成为一个Session

Session 的实现原理与具体的Web容器相关

这里直接了解他的特点:

1. 由于Session属于服务端, 所以在服务端会占用一定的内存与CPU用来处理和计算Session

   这导致了服务器的并发连接量较低

   所以通常会在此之前设置一个静态资源服务器

2. Session同步问题

   现在web应用中, 通常使用的服务器数量都是>=2, 这就导致了每台服务器上的Session不同, 当客户端访问一台服务器时, 为其建立的Session, 之后访问另一台时就将失效

   所以多态服务器提供同一个web服务时, 通常需要进行Session同步, 这又会占用更多的资源

   具体的同步方法直接看参考博客:

   https://blog.csdn.net/shengzhu1/article/details/78036136

常见状态码 & 原因

参考博客

https://www.cnblogs.com/siyunianhua/p/13343538.html

https://blog.csdn.net/banana960531/article/details/85621865

状态码由3个10进制数字组成

状态码分类:

	类别	原因短语
1xx	Informational（信息性状态码）	接受的请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向）	需要进行附加操作以完成请求
4xx	Client error（客户端错误）	客户端请求出错，服务器无法处理请求
5xx	Server Error（服务器错误）	服务器处理请求出错

常见状态码:

**200 OK：**表示从客户端发送给服务器的请求被正常处理并返回；

**204 No Content：**表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；

**206 Patial Content：**表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。

**301 Moved Permanently：**永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；

**302 Found：**临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；

​ 301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）

**303 See Other：**表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；

302与303的区别：后者明确表示客户端应当采用GET方式获取资源

**304 Not Modified：**表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；

**307 Temporary Redirect：**临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；

**400 Bad Request：**表示请求报文中存在语法错误；

**401 Unauthorized：**未经许可，需要通过HTTP认证；

**403 Forbidden：**服务器拒绝该次访问（访问权限出现问题）

**404 Not Found：**表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；

**500 Inter Server Error：**表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；

502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求

**503 Server Unavailable：**表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

更多状态码解析:

1* 信息，服务器收到请求，需要请求者继续执行操作*

100 Continue 继续。客户端应继续其请求

101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

*2* 成功，操作被成功接收并处理

**200 OK 请求成功。一般用于GET与POST请求

201 Created 已创建。成功请求并创建了新的资源

202 Accepted 已接受。已经接受请求，但未处理完成

203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本

204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档

205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域

206 Partial Content 部分内容。服务器成功处理了部分GET请求

3* 重定向，需要进一步的操作以完成请求*

300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择

301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

303 See Other 查看其它地址。与301类似。使用GET和POST请求查看

304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

305 Use Proxy 使用代理。所请求的资源必须通过代理访问

306 Unused 已经被废弃的HTTP状态码

307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向

4* 客户端错误，请求包含语法错误或无法完成请求*

400 Bad Request 客户端请求的语法错误，服务器无法理解

401 Unauthorized 请求要求用户的身份认证

402 Payment Required 保留，将来使用

403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求

404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面

405 Method Not Allowed 客户端请求中的方法被禁止

406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求

407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权

408 Request Time-out 服务器等待客户端发送的请求时间过长，超时

409 Conflict 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突

410 Gone 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置

411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息

412 Precondition Failed 客户端请求信息的先决条件错误

413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息

414 Request-URI Too Large 请求的URI过长（URI通常为网址），服务器无法处理

415 Unsupported Media Type 服务器无法处理请求附带的媒体格式

416 Requested range not satisfiable 客户端请求的范围无效

417 Expectation Failed 服务器无法满足Expect的请求头信息

5* 服务器错误，服务器在处理请求的过程中发生了错误*

500 Internal Server Error 服务器内部错误，无法完成请求

501 Not Implemented 服务器不支持请求的功能，无法完成请求

502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求

505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理

面试题:

URI & URL的区别:

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源

• Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
• URI一般由三部组成：
• ①访问资源的命名机制
• ②存放资源的主机名
• ③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

• URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。

• 采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：

  ①协议(或称为服务方式)

  ②存有该资源的主机IP地址(有时也包括端口号)

  ③主机资源的具体地址。如目录和文件名等

一次完整的HTTP请求经历的7个步骤:

更加完整的步骤参考这里:

https://blog.51cto.com/linux5588/1351007

1. DNS域名解析

   首先浏览器会对域名进行解析, 找到对应的IP地址

2. 建立TCP连接

   在获取到IP地址后, 客户端浏览器会以一个随机端口, 向服务器的80端口发起TCP连接请求, 通过三次握手, 建立TCP连接

3. 建立TCP连接后发起HTTP请求

   通常浏览器使用HTTP的get方法, 请求Web服务器上相应的目录资源

4. 服务器收到HTTP请求并响应, 向客户端返回HTML代码

   通常是返回index.html

5. 浏览器获取到index.html后, 解析HTML代码

   遇到js/css等静态资源时, 就向服务器请求下载, 通常利用keep-alive的特性, 以多线程的形式进行请求,

6. 之后, 浏览器对根据HTML语法对页面进行渲染, 并呈现给用户

HTTPS

参考博客:

https://blog.csdn.net/xiaoming100001/article/details/81109617

基于HTTP协议，通过SSL(Security Socket Layer)或TLS提供加密处理数据、验证对方身份以及数据完整性保护

这里主要是对比与HTTP的区别

特点:

1. 内容加密：采用混合加密技术，中间者无法直接查看明文内容
2. 验证身份：通过证书认证客户端访问的是自己的服务器
3. 保护数据完整性：防止传输的内容被中间人冒充或者篡改

HTTPS认证过程:

参考博客:

https://blog.csdn.net/duanbokan/article/details/50847612

这里类似于SHH, 同样是交换公钥, 但具体过程有别

这个是另一个地方看的, 与图中的有部分不同

1. 服务器预先用RSA生成公钥 & 私钥
2. 将公钥放到证书中, 发送给客户端, 私钥自己保存
3. 客户端收到证书后, 向本地权威服务器验证证书的合法性, 如果证书合法, 则客户端产生一个随机数作为RSA公钥, 并由公钥加密后, 发送至服务器
4. 服务器用私钥解锁这段随机数, 获取客户端公钥

此时C,S两端都获得了对方的公钥, 可以建立连接

单向认证:

双向认证

HTTP & HTTPS优缺点对比:

1. SSL证书需要购买申请
2. SSL证书需要绑定IP, 无法在同一IP上绑定多个域名
3. 需要浏览器支持HTTPS
4. 使用HTTPS会增加页面的加载时间(50%), 即https没有http高效
5. HTTPS协议占用的服务端资源更多, 相对而言要投入更大的成本

FTP

参考博客:

https://blog.csdn.net/zhubao124/article/details/81662775

https://zhuanlan.zhihu.com/p/141472331

ftp使用两个端口:

• 数据端口20
• 命令端口21

每次FTP命令发送后, FTP server 都会返回一个字符串, 其中包括一个响应代码和说明信息, 用于判定命令是否执行成功

参考这个模型:

其中:

控制连接:

• USER-PI(protocol interpreter):用户协议解释器
• SERVER-PI:服务器协议解释器

数据连接:

• user-DTP(Data Transfer Process):用户数据传输进程
• server-DTP:服务器数据传输进程

与HTTP相比的特点:

1. 控制连接: 带外发送控制信息（对比 HTTP 带内控制信息）
2. FTP 服务器要维护用户状态信息: 当前目录, 先前的身份认证（对比HTTP的无状态连接）

工作流程:

1. FTP客户首先发起建立1个与FTP服务器端口号21之间的TCP控制连接, 指定TCP作为传输层协议
2. 客户在建立的控制连接上获得身份认证
3. 客户在建立的控制连接上发送命令来浏览远程主机的目录.
4. 当服务器接收到1个文件传输命令时, 在服务器端口号20创建1个与客户 的TCP数据连接
5. 1个文件传输后,服务器结束这个TCP数据连接.
6. 之后 再次传输，服务器创建第2个TCP与客户的数据连接来传输下一个文件.

控制端口

在FTP连接之初, 会先有一个Socket建立控制端口, 用于发送&返回一些响应信息

如身份验证, 目录浏览, 文件删除等

数据端口

在确认文件传输请求之后, 会建立一个Socket连接20端口, 用于数据传输

这里分为主动模式 & 被动模式

工作模式

1. 主动模式(PORT):

   客户端发送PORT命令以建立命令连接

   PORT(h1, h2, h3, h4, p1, p2)
   

   其中:

   • h1-h4是IP地址

   • p1-p2用于计算端口号
     $$实际端口号=P1\ast 256+P2$$

   这里注意一下客户端&服务端开放与监听的端口

   主动模式下，客户端随机打开一个大于 1024 的端口向服务器的命令端口 P，即 21 端口，发起连接，同时开放N +1 端口监听，并向服务器发出 “port N+1” 命令，由服务器从它自己的数据端口 (20) 主动连接到客户端指定的数据端口 (N+1)

   此种模式下FTP 的客户端只是告诉服务器自己的端口号，让服务器来连接客户端指定的端口。对于客户端的防火墙来说，这是从外部到内部的连接，可能会被阻塞

2. 被动模式(PASV)

   为了解决上述被防火墙拦截的问题, 有了被动模式, 此模式下命令连接 & 数据连接 都有客服端发起

   1. 客户端发送PASV命令

3. 服务器返回监听的地址和端口号

   3. 客户端发起数据连接

   具体过程为:

   被动模式下，当开启一个 FTP 连接时，客户端打开两个任意的本地端口 (N > 1024 和 N+1)

   第一个端口连接服务器的 21 端口，提交 PASV 命令, 然后接收服务器返回的信息(其结构与PORT相同), 解析出服务器IP与开放的用来进行数据传输的端口

   之后, 客户端用N+1 号端口连接服务器IP+端口, 进行数据传输

NFS

Network File System，网络文件系统

NFS本身是一个非常简单的协议, 其本身并没有提供信息传输协议和功能, 其传输功能是基于其他传输协议
主要用到了RPC (Remote Procedure Call), 所以在启动NFS服务器之后, 需要启动RPC服务

直接参考后头的RPC

NFS特性:

参考博客:

https://zhuanlan.zhihu.com/p/31626338

安全性

NFS默认没有加密, 仅依靠IP或主机名来决定是否允许客户端挂载目录

但NFS支持认证 & 加密

共享资源的属主、属组和权限

NFS 服务器和客户端通过 UID 和 GID 来识别共享资源的所有者信息

当客户端挂载 NFS 共享目录时，共享目录中资源的 UID 和 GID 将与服务器上面的保持一致；而客户端会将 UID 和 GID 映射到客户端上所对应的用户名和组名

例子:

举个例子吧，服务器上有名为 server 的用户，其 UID 为 111；客户端上有名为 client 的用户，其 UID 同为 111。

那么，UID 为 111 的共享资源在服务器上的属主是 server；在客户端上的属主则是 client

RPC

参考博客:

https://www.jianshu.com/p/7d6853140e13

https://developer.51cto.com/art/201906/597963.htm

https://www.zhihu.com/question/25536695

RPC（Remote Procedure Call）远程过程调用
简单的理解是一个节点请求另一个节点提供的服务

这里仅仅是简单理解一下

RPC过程:

对比一下本地过程调用:

如果需要将本地student对象的age+1，可以实现一个addAge()方法，将student对象传入，对年龄进行更新之后返回即可，本地方法调用的函数体通过函数指针来指定

对于远程过程调用:

1. 首先客户端需要告诉服务器，需要调用的函数，这里函数和进程ID存在一个映射，客户端远程调用时，需要查一下函数，找到对应的ID，然后执行函数的代码。
2. 客户端需要把本地参数传给远程函数，本地调用的过程中，直接压栈即可，但是在远程调用过程中不再同一个内存里，无法直接传递函数的参数，因此需要客户端把参数转换成字节流，传给服务端，然后服务端将字节流转换成自身能读取的格式，是一个序列化和反序列化的过程。
3. 数据准备好了之后，如何进行传输？网络传输层需要把调用的ID和序列化后的参数传给服务端，然后把计算好的结果序列化传给客户端，因此TCP层即可完成上述过程，gRPC中采用的是HTTP2协议

Client & Server端执行过程比较:

Client端

1. 将这个调用映射为Call ID。
2. 将Call ID，student（params）序列化，以二进制形式打包
3. 把2中得到的数据包发送给ServerAddr，这需要使用网络传输层
4. 等待服务器返回结果
5. 如果服务器调用成功，那么就将结果反序列化，并赋给student，年龄更新

Server端

1. 在本地维护一个Call ID到函数指针的映射call_id_map，可以用Map callIdMap
2. 等待客户端请求
3. 得到一个请求后，将其数据包反序列化，得到Call ID
4. 通过在callIdMap中查找，得到相应的函数指针
5. 将student（params）反序列化后，在本地调用addAge()函数，得到结果
6. 将student结果序列化后通过网络返回给Client

• 客户端(Client)：服务调用方。
• 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
• 服务端存根(Server Stub)：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
• 服务端(Server)：服务的真正提供者。
• Network Service：底层传输，可以是 TCP 或 HTTP

RPC核心框架:

Telnet

参考博客:

https://blog.csdn.net/weixin_40752764/article/details/84391436

https://www.cnblogs.com/binarylei/p/8964646.html

Telnet最重要的是解决了远程连接计算机时的异构性(在不同的平台和系统中的互操作性)

Telnet基于三个原理：网络虚拟终端（NVT）.协商原理.终端和进程的对称观

1. 网络虚拟终端(NVT)

   为了支持异构性, Telnet使用了NVT

   NVT是数据和命令顺序的标准表示方法, , 是C/S体系中的一种实现

   其主要作用是用于将异构的计算机系统间的通信翻译为相互可理解的物理设备指令

2. 协商原理

   不同的系统间通信, 一些系统可能提供较多的功能, 较少功能的系统在与之通信时, 可能无法正常运作

   所以Telnet在通信时, 通信和终端参数是在连接过程中确定的, 任何一方无法提供的服务或进程将被忽略, 这就减少了通信过程中对交换信息的解释需求

3. 中断和进程的对称观

   这意味着协商语法的对称性，既允许用户也允许服务器请求指定的选项。这种终端和进程的对称观优化了由另一端提供的服务。Telnet不仅允许终端与远程应用交互，还允许进程——进程和终端——终端的交互

Telnet缺点:

使用Telnet传输数据时效率不高

数据信息被用户从本地键盘键入并通过操作系统传到客户机程序，客户机程序将其处理后返回操作系统，并由操作系统经过网络传送到远地机器，远地操作系统将所接收数据传给服务器程序，并经服务器程序再次处理后返回到操作系统上的伪终端入口点，最后，远地操作系统将数据传送到用户正在运行的应用程序，这便是一次完整的输入过程；输出将按照同一通路从服务器传送到客户机

因为每一次的输入和输出，计算机将切换进程环境好几次，这个开销是很昂贵的

SSH

参考博客:

https://blog.csdn.net/vevenlcf/article/details/43273405

Secure Shell, 使用的最多的元辰登录和传输文件的协议

使用RSA非对称性加密

SSH连接过程:

1. 服务器 & 客户端建立公私钥
2. 客户端请求连接
3. 服务器接到客户端请求, 将自身公钥传回给客户端
4. 客户端收到服务器公钥后, 对比本地公钥表, 如果相同, 则进入下一步, 如果未找到, 则新增一个公钥, 如果主机名与记录的公钥不相同, 则警告
5. 客户端发送自己的公钥给服务器
6. 连接建立成功

此时客户端 & 服务器均保持有自身的私钥和对方的公钥, 能够进行双向加密

SSH工作阶段:

1. 版本号协商阶段

   当前有两个版本: SSH1 & SSH2 会话双方自动协商使用的版本

2. 秘钥 & 算法协商阶段

   SSH支持多种加密方案, 会话双方自动选择使用的加密方法

3. 认证阶段

   SSH客户端向服务器端发起认证请求， 服务器端对客户端进行认证

4. 会话请求阶段

   认证通过后，客户端向服务器端发送会话请求

5. 交互会话阶段

   会话请求通过后，服务器端和客户端进行信息的交互

几个过程:

加密 & 解密:

这里就要了解到RSA非对称加密算法

其核心是: 使用公钥加密的数据, 只能使用对应的私钥解密

SSH的会话双方同时持有对方的公钥和自己的私钥, 在发送数据时, 使用对方的公钥进行加密, 而对方收到公钥后, 使用自己私钥进行解密

这样, 假设加密后的数据被第三方截获, 第三方也因为没有私钥而无法解密

验证数据一致性:

通常采用的方法是Hash散列, 发送端将hash值同数据一同发送, 接收端在接收到数据之后, 进行一次hash散列并比较, 如果两次的值相同, 则证明数据是完整的

身份验证:

在加密 & 解密过程中, 需要获取到对方的公钥, 但是, 如何保证发来公钥的一方是我们想要的会话对象呢?

这里就涉及到身份验证, 这将在后头的协议详解中了解到

SSH2协议详细过程:

其中几个关键的Key

1. session key:
   这个是用来作为secret key加密用的一个key，同时也作为每个ssh连接的标识ID。
2. host key:
   这个是用来作为server的身份验证用的。
3. known-hosts:
   这个是存在客户端的一个可信server的public key列表。
4. user key:
   这个是用来作为client的身份验证用的

SSH2的详细过程:

图中涉及到3个SSH2的子协议:

• SSH-TRANS

  传输协议, 定义了传输的包和加密的通道, 其他两个协议建立在这个协议之上

• SSH-AUTH

  此协议用于验证客户端的身份, 途中可以看到, 其传送了username & passwd, 但由于是建立在SSH-TRANS上的, 所以仍然安全

• SSH-CONN

  SSH2中真正的应用协议

  在这里可以定义各种不同的SSH协议, 如常用的scp, sftp等

  此协议需要经过SSH-AUTH验证之后才能使用

其余的详细数据过程参考这个博客:

https://blog.csdn.net/vevenlcf/article/details/43273405

VPN

参考博客:

https://www.seoxiehui.cn/article-72334-1.html

https://www.wper.com/zixun/201908/2964.html

Virtual Private Network 虚拟私人网络

VPN具有多个协议, 这里仅了解几个常用的协议

PPTP

L2TP

IPSec

SSLVPN

OpenVPN

ICMP

在IP通信过程中, 经常有一些问题导致数据包没有成功到达指定位置, 诸如丢包, 端口号错误等, 而ICMP保温就是为了传递这些信息

ICMP 协议是为了辅助IP 协议，交换各种各样的控制信息而被制造出来的

ICMP大致分为两种功能:

1. 差错通知

   在IP数据包传送过程中如果出错, ICMP需要负责传送这个错误信息与原因

2. 信息查询

   信息查询在送信放向目标计算机询问时发生, 云纹的种类非常丰富, 如ping等使用的就是ICMP

这里了解几个基于ICMP的应用

ping命令:

ping命令作为最常用的网络命令, 用于调查两台计算机在IP层次上是否联通, 调查数据包往返需要多长时间

几个步骤:

ping命令本身是非常简单的, 如上图所示:

ping命令使用两个ICMP包, 结构就是图中的样子, , 服务器受到

1. 客户端向服务器发送一个ICMP包
2. 服务器收到这个包后, 发送一个回送请求
   其内容与收到的包几乎一模一样, 只不过修改了源&目标IP地址
3. 客户端收到回送的ICMP包, 判断是否是与发送的ICMP包相对应, 如果是, 则计算往返时间

ping不到的几个原因:

1. 目标服务器不存在
2. 数据包往返时间过长, 导致ping超时
3. 目标服务器不应答

traceroute命令

这里先简单了解一下这个命令是干啥的

用来显示两个主机之间的通信走的什么路径, 如:

其中的每一个节点都是路由器(二层交换机本身不显示)

相当于查看了访问过程中经过的路由器, 并对每个路由器都进行了一次ping操作

那三个时间就是三次发ICMP报文的回送响应时间, 与ping相同

工作原理:

参考博客:

https://blog.csdn.net/microtong/article/details/3220450

这个留到以后再说吧

SMTP

参考博客:

https://blog.csdn.net/sinat_36219858/article/details/71069515

Simple Mail Transfer Protocol 简单有阿金传输协议

客户端只能使用SMTP发送邮件, 而服务端可以使用POP3, IMAP, SMTP等发送/接收邮件

SMTP默认使用端口号25

SMTP模型:

SMTP步骤:

SMTP有3个步骤:

1. 发送MAIL命令

   MAIL <SP> FROM:<reverse-path> <CRLF>
   

   此命令是告诉接收这, 开始一个新的邮件事物, 重置所有状态接收表和缓冲区(其中包括了接受者的信息 & 邮件数据)

   被用于报告错误

   如果命令被接受，返回250 OK

2. 发送 RCPT 命令

   RCPT <SP> TO:<forward-path> <CRLF>
   

   此命令用于提供一个接受者邮箱

   如果被接收, 接收端会返回一个250 OK

   如果不能识别, 则返回550 Failure

   这个命令能被执行多次

3. 发送 DATA 命令

   DATA <CRLF>
   

   如果被接受, 则返回一个354, 并认为所有后续发来的数据行都是邮件的数据信息

   当接收到文本结束符.是, 返回250 OK

   邮件结束的末尾必须用.作为独立的一行表示

常见攻击手段

DDoS

Distributed Denial of Service 分布式拒绝服务, 又称作泛洪攻击

快速形象了解可以参考这篇:

https://www.zhihu.com/question/22259175

详细了解参考这个:

https://blog.csdn.net/qq_37865996/article/details/84636020

https://blog.csdn.net/weixin_44489066/article/details/87934156

• 黑客（Intruder/Attacker/Client） 黑客操作主机的接口，向Master发送各种命令。
• 主控端（Master/Handler） 监听Intruder的命令，向各个Daemon发送攻击命令。
• 守护进程端（Daemon/Slave/Agent/Zombie/Bot/Server） 接收和响应来自Master的攻击命令，是真正攻击前锋。
• 受害者（Victim）被攻击的目标主机

DDoS攻击过程:

1. 构造攻击网络

   也就是控制肉鸡的过程, 通常需要较长时间

2. 发动攻击

   迅速而猛烈, 并且在攻击过后需要迅速瓦解网络

DDoS攻击特点:

• 用于通信的ICMP消息不需要明确的端口号，避免被IDS检测到——TFN2K
• 哪里阻止DDoS，哪里就受到攻击——防火墙
• 源IP地址可以伪装，但攻击路径不能伪装——防火墙过滤进出的伪造源IP地址的数据包。所以攻击一旦进行之后，要立即瓦解网络，防止追踪。
• IP溯源技术只能追踪到攻击者所在的网关

DDoS攻击模式:

这里暂时不进行了解, 毕竟不是DDoS的发起方, 而是防御方

需要的话直接看参考博客

DDoS检测方法 & 对策

检测方法:

• DNS服务器会收到大量反向解析目标IP主机名的PTR查询请求；

• 出现明显超出网络正常工作时极限的通信流量的现象；

• 检测特大型的ICMP和UDP数据包（含有加密后的目标地址和一些命令选项的控制信息）；

• 检测不属于正常连接通信的TCP和UDP数据包（如对高于1024端口的连接请求）。

对策:

• 解决OS/网络服务和应用的漏洞问题。

• 监视网络流量及通信过程，严格设置过滤规则。

• 优化网络结构和路由表，减少受攻击的影响。

• 使用负载均衡和蜜罐技术抵御这种攻击。

• 使用find_ddos/Zombie Zapper/DDoSPing发现系统是否被种植DDoS工具。

• 攻击发生时能迅速检测攻击并实施过滤，攻击进行时或结束后能追踪攻击源。

Sql注入

参考博客:

https://www.cnblogs.com/myseries/p/10821372.html

https://blog.csdn.net/weixin_43915762/article/details/87909751

SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至篡改数据库

SQL注入是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统

这个玩意还挺复杂的, 具体的直接看参考博客吧

​