小舞很执着

这个屌丝很懒，什么也没留下！

热门标签

计算机网络面试_发送缓存区和发送窗口

作者：小舞很执着 | 2024-07-22 07:41:24

踩

发送缓存区和发送窗口

计算机网络

一、计算机网络概述

不同位置的多台计算机机器设备，通过通信线路连接起来，在操作系统以及通信协议的管理下，实现资源共享，和信息管理传递的计算机网络。组成包括，计算机、传输介质、网络操作系统以及相应的软件（前面两个软件后面两个硬件）

1、网络设备

1.1网卡

每一网卡都有唯一的编号，这个号码叫做MAC地址，其功能主要有两个，一是将计算机的数据进行封装，通过通信线路发布到网上。二是接收网络上传来的数据，传到计算机中。

1.2 交换机

交换机与集线器一样，但性能却优于集线器。1000Mb/s的交换机的每个端口都是1000Mb/s，互联的每台计算机均以1000Mb/s进行通信，而不像集线器那样平分带宽。交换机的工作原理：交换机从某一节点收到一个以太网帧后，便在其内存中地址表进行查找（MAC地址），如果有就将数据传输到该地址，如果没有就将该数据包广播到所有节点，与此匹配的MAC地址收到后就会做出应答，最后交换机就可以将这个地址保存到MAC地址表。

1.2 路由器

路由器主要连接不同网络，所谓路由功能指的是在不同网络之间选择最佳的信息传输路径，从而使信息更快的传输到目的地。

2、OSI 七层模型

OSI（open system interconnection），开放式系统互联参考模型，七层结构记忆方法：应、表、会、传、网、数、物。
这个模型把网路协议分为七层，每一层对应相关的物理设备，OSI七层模型是一种框架性的设计方案，主要是用来解决异构网络互连时所遇到的兼容性问题，用来帮助不同类型的主机实现数据传输。模型最大的优点在于将服务、接口、协议分开。服务说明某一层为上一层提供什么功能，接口说明上一层如何使用下一层的服务，而协议则涉及如何实现本层的功能。

2.1数据传输过程

这里写图片描述
中间的常规路由器设备是由三层交换设备，常规的交换机是两层交换设备。

2.2具体各层介绍

物理层：定义物理设备标准，比如网线的接口类型，光纤的接口类型，传输介质的传输速率。主要作用是传输数据流
数据链路层：定义如何让格式化数据传输，如何控制对物理层的访问。其主要功能是如何在不可靠的物理线路上进行数据的可靠传递。保证传输的可靠性。
数据链路层主要设备：二层交换机、网桥、网卡
网络层：给两个不同的主系统提供链接和路径选择。
网络层主要设备：路由器
传输层：定义传输数据的协议和端口号（www协议，使用80端口），TCP（传输控制协议），UDP（用户数据报协议）
会话层：认为是一次通讯的过程，通过传输层建立数据传输的通路（设备的连接可以是IP或者MAC或者主机名）
表示层：这一层确保一个系统的应用层所发出的信息可以被另一个系统接收。两个系统之间可能传输和接收数据的格式不一样，需要表示层来进行数据格式转换。
应用层：用户的应用程序，应用层协议的代表包括：Telnet、FTP、HTTP、SNMP、DNS等。

2.3 每一层的数据变化

这里写图片描述

3、TCP/IP四层模型

OSI七层模型是一个参考模型，真正使用的是TCP/IP模型。**TCP/IP（Transmission Control Protocol/Internet Protocol）**是传输控制协议和网络协议的简称，它定义了电子设备如何连入因特网，以及数据如何在它们之间传输的标准。
TCP/IP 不是一个协议，而是一个协议族的统称，里面包括了 IP 协议、ICMP 协议、TCP 协议、以及 http、ftp、pop3、https 协议等。网络中的计算机都采用这套协议族进行互联。
模型对应图：
这里写图片描述

3.1 每一层负责的功能

链路层：链路层也叫网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。
网络层：也叫互联网层，处理分组的网络活动。TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（互联网控制报文协议），以及IGMP协议（internet组管理协议）
运输层：主要为两个主机的应用程序提供端到端的通信。TCP/IP协议族中，有两个互不相同的协议TCP协议，UDP协议。
应用层：负责处理特定的应用程序细节。应用层面向不同的网络应用引入了不同的应用层协议。其中，有基于TCP协议的，如文件传输协议（File Transfer Protocol，FTP）、虚拟终端协议（TELNET）、超文本链接协议（Hyper Text Transfer Protocol，HTTP），也有基于UDP协议的。

3. 2 基于TCP/IP协议族的主机间通讯协议过程

这里写图片描述

TCP和UDP是两种最为著名的运输协议，二者都使用IP作为网络层协议。IP是网络层上的主要协议，ICMP是IP协议的附属协议，IP层用它来与其他主机或者路由器交换错误报文和其他重要信息，IGMP是internet组管理协议，它用来把一个UDP数据报播到多个主机。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网，令牌环网）使用的特许协议，用来转换IP层和网络接口层协议。

3.3 TCP/IP数据包封装

这里写图片描述
传输层TCP传给网络层IP的数据单元称作TCP报文段，TCP段。IP传给接口层的数据单元称作IP数据段。

3.3 TCP/IP数据包分发

主机收到一个数据包时，数据就开始从协议栈中由底层向上升，同时去掉各层协议加上的报文首部，每层协议盒都要检查报文首部中的协议标识，以确定接收数据的上层协议，这个过程叫做分用。
这里写图片描述

二、IP协议概述

IP协议是TCP/IP协议的核心，所有的TCP，UDP，IMCP，IGMP的数据都以IP数据格式传输。要注意的是，IP提供不可靠、无连接的数据传送，赖其他层的协议进行差错控制。不可靠指的是IP数据报不保证能成功的到达目的地，如果出现错误则选择丢弃该数据，然后发送ICMP消息报给信源端。无连接指的是IP不提供任何后续数据报的状态信息，每个数据报处理都是独立的。如果一个信源发送了连续的两个数据报，每个数据报选择独立的路由，两个数据可能不同时到达。

4.1 IP协议消息头

这里写图片描述
(1) 版本号：IP协议的版本。对于IPv4来说值是4
(2) 头部长度：4位最大为0xF，注意该字段表示单位是字(4字节)
(3) 服务类型(Type Of Service，TOS)：3位优先权字段(现已被忽略) + 4位TOS字段 + 1位保留字段(须为0)。4位TOS字段分别表示最小延时、最大吞吐量、最高可靠性、最小费用，其中最多有一个能置为1。应用程序根据实际需要来设置 TOS值，如ssh和telnet这样的登录程序需要的是最小延时的服务，文件传输ftp需要的是最大吞吐量的服务。
(4) 总长度: 指整个IP数据报的长度，单位为字节，即IP数据报的最大长度为65535字节(2的16次方)。利用首部长度字段和总长度字段，就可以知道IP数据报中的数据内容的启始位置和长度。
(5) 标识：唯一地标识主机发送的每一个数据报，其初始值是随机的，每发送一个数据报其值就加1。同一个数据报的所有分片都具有相同的标识值
(6) 标志: 位1保留，位2表禁止分片(DF)，若设置了此位，IP模块将不对数据报进行分片，在此情况下若IP数据报超过MTU，IP模块将丢弃数据报并返回一个ICMP差错报文；位3标识更多分片(MF)，除了数据报的最后一个分片，其他分片都要把它设置为1
(7) 位偏移：分片相对原始IP数据报数据部分的偏移。实际的偏移值为该值左移3位后得到的，所以除了最后一个IP数据报分片外，每个IP分片的数据部分的长度都必须是8的整数倍

(8) 生存时间（TTL）:：数据报到达目的地之前允许经过的路由器跳数。TTL值被发送端设置，常设置为64。数据报在转发过程中每经过一个路由该值就被路由器减1.当TTL值为0时，路由器就将该数据包丢弃，并向源端发送一个ICMP差错报文。
(9) 协议: 区分IP协议上的上层协议。在Linux系统的/etc/protocols文件中定义了所有上层协议对应的协议字段，ICMP为1，TCP为6，UDP为17
(10) 首部校验和：由发送端填充接收端对其使用CRC算法校验，检查IP数据报头部在传输过程中是否损坏
(11) 源IP地址和目的IP地址: 表示数据报的发送端和接收端。一般情况下这两个地址在整个数据报传递过程中保持不变，不论中间经过多少个路由器
(12) 选项：可变长的可选信息，最多包含40字节。选项字段很少被使用。可用的IP可选项有：
a. 记录路由: 记录数据包途径的所有路由的IP，这样可以追踪数据包的传递路径
b. 时间戳: 记录每个路由器数据报被转发的时间或者时间与IP地址对，这样就可以测量途径路由之间数据报的传输的时间
c. 松散路由选择: 指定路由器的IP地址列表数据发送过程中必须经过所有的路由器
d. 严格路由选择: 数据包只能经过被指定的IP地址列表的路由器
e. 上层协议(如TCP/UDP)的头部信息

4.2 IP路由选择

IP层在内存中有一个路由表，当收到一份数据报时并进行发送时，它都要对该表进行搜索一次，当数据报来自某个网络接口时，IP首先检查目的IP地址是否为本机IP地址之一或者IP广播地址。如果是这样，数据就被送到IP首部协议字段所指的协议模块进行处理。如果不是，有路由功能时就进行转发，要么就丢弃。

4.2 IP地址介绍

1）IP地址是32位二进制数，每八个为一段，共四段，10000011.01101011.00010000.11001000，转换成十进制就是130.107.16.200
2）IP地址由网络ID和主机ID组成，网络ID表明所在网络的编号，主机ID表明计算机的编号。
3）IP地址分为A、B、C、D、E五类
这里写图片描述
也就是说，分为以下几类：
A: 0.0.0.0-127.255.255，其中段0和127不可用
B: 128.0.0.0-191.255.255.255
C: 192.0.0.0-223.255.255.255
D: 224.0.0.0-239.255.255.255
E: 240.0.0.0-255.255.255.255，其中段255不可用

这其中除了段0和段127之外，还有一些IP地址因为有其他的用途，是不可以用作普通IP的。还有一部分被用作私有IP地址。
这里写图片描述

4.2 子网掩码

计算机联网时必须有公有IP地址，除了IP地址外主机还需要知道多少比特用于子网掩码，以及多少用于主机号，子网掩码是一个32bit值，值为1的比特留给网络号和子网号，为0的比特留给主机号。子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。

4.3 域名地址（DNS）

由解析器和域名服务器组成。域名服务器是指保存有该网络中所有主机域名和对应IP地址，并具有将域名转换成IP地址功能的服务器。域名解析是指将域名映射为IP地址

三、 TCP协议

TCP将用户数据打包构成报文段，它发送数据时启动一个定时器，另一端收到数据进行确认，对失序的数据重新排序，丢弃重复的数据。TCP提供一种面向连接的可靠的字节流服务，面向连接意味着两个使用TCP的应用（B/S）在彼此交换数据之前，必须先建立一个TCP连接，类似于打电话过程，先拨号振铃，等待对方说喂，然后应答。在一个TCP连接中，只有两方彼此通信。
TCP可靠性来自于：
（1）应用数据被分成TCP最合适的发送数据块
（2）当TCP发送一个段之后，启动一个定时器，等待目的点确认收到报文，如果不能及时收到一个确认，将重发这个报文。
（3）当TCP收到连接端发来的数据，就会推迟几分之一秒发送一个确认。
（4）TCP将保持它首部和数据的检验和，这是一个端对端的检验和，目的在于检测数据在传输过程中是否发生变化。（有错误，就不确认，发送端就会重发）
（5）TCP是以IP报文来传送，IP数据是无序的，TCP收到所有数据后进行排序，再交给应用层
（6）IP数据报会重复，所以TCP会去重
（7）TCP能提供流量控制，TCP连接的每一个地方都有固定的缓冲空间。TCP的接收端只允许另一端发送缓存区能接纳的数据。
（8）TCP对字节流不做任何解释，对字节流的解释由TCP连接的双方应用层解释。

5.2 TCP消息

图片来自网络
TCP数据是封装在一个IP数据中。

5.2.1 TCP消息头

这里写图片描述
　●源、目标端口号字段：占16比特。TCP协议通过使用”端口”来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。在收到服务请求时，操作系统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在”众所周知的端口”（Well-Know Port）为用户提供服务。
　●顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
　●确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。
　●头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。
　●标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：
　◆URG：紧急指针（urgent pointer）有效。
　◆ACK：为1时，确认序号有效。
　◆PSH：为1时，接收方应该尽快将这个报文段交给应用层。
　◆RST：为1时，重建连接。
　◆SYN：为1时，同步程序，发起一个连接。
　◆FIN：为1时，发送端完成任务，释放一个连接。
　●窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。
　●TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
　●紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
　●选项字段：占32比特。可能包括”窗口扩大因子”、”时间戳”等选项。

5.3 TCP建立三次连接的过程（三次握手）

TCP是一个面向连接的协议，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接，建立一条连接有以下过程。

第一次握手：client首先发送SYN（Synchronization）报文给server，此时，client进入SYN_SENT状态，等待server端确认；注：SYN报文的特点：SYN标识位置1，随机产生一个值seq=X，占用一个序列号。

第二次握手**：**server收到client发过来的SYN包后知道client请求建立连接，将产生一个SYN+ACK包发送给client以确认连接请求，此时server进入SYN_RCVD状态；注：SYN+ACK包的特点：SYN和ACK标识位都为1，ack=X+1,随机产生的seq=Y。

第三次握手：client收到server的SYN+ACK包，向server发送确认包ACK(ack=Y+1），此包发送完毕，client和server进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据，其实在第三次握手的同时，client就可以向sever发送数据了。这里写图片描述

TCP报文格式简介

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1SlEg0sz-1602738063281)(https://pics3.baidu.com/feed/64380cd7912397ddb480a4110c5c4ab2d1a28709.jpeg?token=45d9d76830f1e8052a5f5394378e459a&s=048A5F31C60E77495EC7C14D0300C0E2)]

其中比较重要的字段有：

（1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

（2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

（3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

URG：紧急指针（urgent pointer）有效。ACK：确认序号有效。PSH：接收方应该尽快将这个报文交给应用层。RST：重置连接。SYN：发起一个新连接。FIN：释放一个连接。

需要注意的是：

不要将确认序号Ack与标志位中的ACK搞混了。确认方Ack=发起方Seq+1，两端配对。

”三次握手”的详解

所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：

在这里插入图片描述

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）首先客户端向服务器端发送一段TCP报文，其中：

标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；随后客户端进入SYN-SENT阶段。
（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；序号为Seq=y；确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。

（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；随后客户端进入ESTABLISHED阶段。服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。

弄懂了上面的过程，我们来看看什么是SYN攻击：

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列（内核会为每个这样的连接分配资源的），导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了

5.3 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状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
3、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
4、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
这里写图片描述

2、“四次挥手”的详解

所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：

在这里插入图片描述

挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：

（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：

标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

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

标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL

为什么要客户端要等待2MSL呢？见后文。

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

客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

3.为什么“握手”是三次，“挥手”却要四次？

TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

所以是“三次握手”，“四次挥手”。

4.为什么客户端在TIME-WAIT阶段要等2MSL?

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

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因

请简述TCP/UDP的区别

TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输。
两者的区别大致如下：

TCP面向连接，UDP面向非连接即发送数据前不需要建立链接
TCP提供可靠的服务（数据传输），UDP无法保证
TCP面向字节流，UDP面向报文
TCP数据传输慢，UDP数据传输快
TCP提供一种面向连接的、可靠的字节流服务
在一个TCP连接中，仅有两方进行彼此通信，因此广播和多播不能用于TCP
TCP使用校验和，确认和重传机制来保证可靠传输
TCP使用累积确认
TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

TCP和UDP的应用场景

TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。
在日常生活中，常见使用TCP协议的应用如：浏览器，用的HTTP；``FlashFXP，用的FTP；``Outlook，用的POP、SMTP；``Putty，用的Telnet、SSH；``QQ文件传输

UDP：当强调传输性能而不是传输的完整性时，要求网络通讯速度能尽量的快。如：QQ语音 QQ视频等。

TCP对应的协议和UDP对应的协议

TCP对应的协议：

FTP：定义了文件传输协议，使用21端口。
Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
HTTP：是从Web服务器传输超文本到本地浏览器的传送协议，端口默认80。

UDP对应的协议：

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File TransferProtocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。

为什么 TCP 叫数据流模式？ UDP 叫数据报模式？

所谓的**“流模式”，是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的**，比如你通过 TCP连接给另一端发送数据，你只调用了一次 write，发送了100个字节，但是对方可以分10次收完，每次10个字节；你也可以调用10次write，每次10个字节，但是对方可以一次就收完。
原因：这是因为TCP是面向连接的，一个 socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。

所谓的**“数据报模式”，是指UDP发送端调用了几次 write，接收端必须用相同次数的 read 读完**。UDP是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。
原因：这是因为UDP是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。

TCP中的流量控制和拥塞控制

注：tcp协议如何保证传输的可靠性。TCP协议作为一个可靠的面向流的传输协议，其可靠性和流量控制由滑动窗口协议保证，而拥塞控制则由控制窗口结合一系列的控制算法实现。

一、滑动窗口协议

TCP的精髓：滑动窗口协议。

所谓滑动窗口协议，自己理解有两点：

“窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”；
“滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提：
1. TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子；
2. 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
4. 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；
  
  TCP建立连接的初始，B会告诉A自己的接收窗口大小，比如为‘20’：
  字节31-50为发送窗口
  
  A发送11个字节后，发送窗口位置不变，B接收到了乱序的数据分组：
  
  只有当A成功发送了数据，即发送的数据得到了B的确认之后，才会移动滑动窗口离开已发送的数据；同时B则确认连续的数据分组，对于乱序的分组则先接收下来，避免网络重复传递：

二、流量控制

流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。

流量控制
所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送：

这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。
传递效率
一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：
1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；
  对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

三、拥塞控制

网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：
\1. 慢开始、拥塞控制
\2. 快重传、快恢复
一切的基础还是慢开始，这种方法的思路是这样的：
-1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
-2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
-3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；
-4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
-5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
*1. cwnd < ssthresh，继续使用慢开始算法；
*2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
*3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；
-6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
-7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；

上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：
-1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
-2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
-3. 此时发送方开始执行“快恢复”算法：
*1. 慢开始门限减半；
*2. cwnd设为慢开始门限减半后的数值；
*3. 执行拥塞避免算法（高起点，线性增长）；

TCP粘包问题

1. 什么是粘包现象

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

2. 为什么出现粘包现象

（1）发送方原因

我们知道，TCP默认会使用Nagle算法。而Nagle算法主要做两件事：1）只有上一个分组得到确认，才会发送下一个分组；2）收集多个小分组，在一个确认到来时一起发送。

所以，正是Nagle算法造成了发送方有可能造成粘包现象。

（2）接收方原因

TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

3 .什么时候需要处理粘包现象

（1）如果发送方发送的多个分组本来就是同一个数据的不同部分，比如一个很大的文件被分成多个分组发送，这时，当然不需要处理粘包的现象；

（2）但如果多个分组本毫不相干，甚至是并列的关系，我们就一定要处理粘包问题了。

4. 如何处理粘包现象

（1）发送方

对于发送方造成的粘包现象，我们可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭Nagle算法。

（2）接收方

遗憾的是TCP并没有处理接收方粘包现象的机制，我们只能在应用层进行处理。

（3）应用层处理

应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。

解决方法就是循环处理：应用程序在处理从缓存读来的分组时，读完一条数据时，就应该循环读下一条数据，直到所有的数据都被处理；但是如何判断每条数据的长度呢？

两种途径：

1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；

2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4字节是数据的长度（一个int来储存数据长度大小），应用层处理时可以根据长度来判断每条数据的开始和结束。

二、ARP/RARP协议

**地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。**主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。地址解析协议是建立在网络中各个主机互相信任的基础上的，网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存；由此攻击者就可以向某一主机发送伪ARP应答报文，使其发送的信息无法到达预期的主机或到达错误的主机，这就构成了一个ARP欺骗。ARP命令可用于查询本机ARP缓存中IP地址和MAC地址的对应关系、添加或删除静态对应关系等。

ARP协议工作流程：

逆地址解析协议，即RARP，功能和ARP协议相对，其将局域网中某个主机的物理地址转换为IP地址，比如局域网中有一台主机只知道物理地址而不知道IP地址，那么可以通过RARP协议发出征求自身IP地址的广播请求，然后由RARP服务器负责回答。

RARP协议工作流程：

（1）给主机发送一个本地的RARP广播，在此广播包中，声明自己的MAC地址并且请求任何收到此请求的RARP服务器分配一个IP地址；

（2）本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址；

（3）如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用；

（4）如果不存在，RARP服务器对此不做任何的响应；

（5）源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。

三、HTTP协议

HTTP协议概述

HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP）。通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。

尽管TCP/IP协议是互联网上最流行的应用，HTTP协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。

通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。

HTTP工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是 HTTP 请求/响应的步骤：

\1. 客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.luffycity.com。

\2. 发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

\3. 服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

\4. 释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

\5. 客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

在浏览器中输入www.baidu.com后执行的全部过程

1、**应用层：**客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。

DNS解析过程

HTTP请求与响应

2、**运输层：**在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层（网络层）的IP地址查找目的端。

3、**网络层：**客户端的网络层不用关心应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。

4、**链路层：**客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。

浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
释放 TCP连接;
浏览器将该 html 文本并显示内容;

http协议是基于TCP/IP协议之上的应用层协议。

基于请求-响应的模式

HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应

无状态保存

HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别,协议对于发送过的请求或响应都不做持久化处理。

使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成如此简单的。可是,随着Web的不断发展,因无状态而导致业务处理变得棘手的情况增多了。比如,用户登录到一家购物网站,即使他跳转到该站的其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管理状态了。有关Cookie的详细内容稍后讲解。

无连接

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次相应一次，服务端和客户端就中断了。但是无连接有两种方式，早期的http协议是一个请求一个响应之后，直接就断开了，但是现在的http协议1.1版本不是直接就断开了，而是等几秒钟，这几秒钟是等什么呢，等着用户有后续的操作，如果用户在这几秒钟之内有新的请求，那么还是通过之前的连接通道来收发消息，如果过了这几秒钟用户没有发送新的请求，那么就会断开连接，这样可以提高效率，减少短时间内建立连接的次数，因为建立连接也是耗时的，默认的好像是3秒中现在，但是这个时间是可以通过咱们后端的代码来调整的，自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间。

HTTP请求方法

HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：

GET

向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

HEAD

与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。

POST

向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。

PUT

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

DELETE

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

TRACE

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

OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

注意事项：

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。例如PATCH（由 RFC 5789 指定的方法）用于将局部修改应用到资源*。*

请求方式: get与post请求（通过form表单我们自己写写看）

GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456.（请求头里面那个content-type做的这种参数形式，后面讲） POST方法是把提交的数据放在HTTP包的请求体中.
GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.
GET与POST请求在服务端获取请求数据方式不同，就是我们自己在服务端取请求数据的时候的方式不同了，这句废话昂。

HTTP状态码

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型：

1xx消息——请求已被服务器接收，继续处理
2xx成功——请求已成功被服务器接收、理解、并接受
3xx重定向——需要后续操作才能完成这一请求
4xx请求错误——请求含有词法错误或者无法被执行
5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，“404 Not Found”，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。

URL

超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：

传送协议。
层级URL标记符号(为[//],固定不变)
访问资源需要的凭证信息（可省略）
服务器。（通常为域名，有时为IP地址）
端口号。（以数字方式表示，若为HTTP的默认值“:80”可省略）
路径。（以“/”字符区别路径中的每一个目录名称）
查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）
片段。以“#”字符为起点

以http://www.luffycity.com:80/news/index.html?id=250&page=1 为例, 其中：

http，是协议；
www.luffycity.com，是服务器；
80，是服务器上的默认网络端口号，默认不显示；
/news/index.html，是路径（URI：直接定位到对应的资源）；
?id=250&page=1，是查询。
大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。

HTTP请求格式(请求协议)

URL包含：/index/index2?a=1&b=2；路径和参数都在这里。

请求头里面的内容举个例子：这个length表示请求体里面的数据长度，其他的请求头里面的这些键值对，陆续我们会讲的，大概知道一下就可以了，其中有一个user-agent，算是需要你记住的吧，就是告诉你的服务端，我是用什么给你发送的请求。

以京东为例，看一下user-agent

看一个爬虫的例子，爬京东的时候没问题，但是爬抽屉的时候必须带着user-agent，因为抽屉对user-agent做了判断，来判断你是不是一个正常的请求，算是反扒机制的一种。

打开我们保存的demo.html文件，然后通过浏览器打开看看就能看到页面效果。

写上面这些内容的意思是让你知道有这么个请求头的存在，有些是有意义的，请求头我们还可以自己定义，就在requests模块里面那个headers={}，这个字典里面加就行。

HTTP响应格式（响应协议）

三、加密

对称加密

定义

对称加密是指加密和解密的密钥为同一个，用来加密数据的密钥同时也可以用来解密；

特点

(1)它的特点是加密速度快，使用简单，因为加密解密只需要同一把钥匙就行了；

(2)对称加密的破解难度是随着钥匙的大小增加而增加的，钥匙越大就越难破解，但是钥匙越大相应的据解密的时间也会越长；

吸取了前面的教训，小芳和小明再也不用明文发送信息了，小芳和小明约定好咱们以后问密码的时候统一在每个原来每个数字上加上1；

有一天小芳又忘记密码了，发信息给小明问银行卡密码=>。

=>小芳：老公银行卡密码是多少。

=>小明：234234。

这时小芳通过之前和小明的约定，进行计算得到密码 123123。当然这次他们的通话也被黑客所偷听，但是他们对数据进行了加密，所以黑客并不知道它们所说的具体内容是什么当然他们银行卡里的钱也安然无恙。

在这个故事中的规则“在原来的每个数字上加1”就相当于对称加密里面的密钥了，加密和解密数据都是使用这一套规则；

对称加密的问题

（1）双方都必须事先约定好加密规则。

（2）密钥的数目难于管理。因为对于每一个合作者都需要使用不同的密钥，很难适应开放互联网中的大量的合作者交流。

（3）无法适用于陌生的网络的环境，双方都必须是可信任的才可进行，而在互联网通信过程中我们通信的双方都是互不相识的，如果双方要约定加密规则，那么势必也要通过网络发送加密秘钥，因为网络环境本身就会存在被窃取的可能，我们发送密钥的请求本身又是不安全的。

运用对称加密有一个前提就是在发送信息前双方都必须知道加密的规则，但是在互联网的环境下我们每天可能跟不同人发送信息，很多人我们之前根本没认识过，这种情况下我们根本不可能事先就约定好加密规则，那么我们就只能通过信息把加密规则（密钥）发送给对方，然后我们再根据加密规则来加密聊天信息，很显然这肯定是不可取的，不经过加密的数据在网络传输是没有任何安全性可言的，于是就出现了非对称加密；

非对称加密

定义

与对称加密不同，非对称加密的密钥是成对的（公钥和私钥）。私钥由自己安全保管不外泄，而公钥则可以发给网络中的任何人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。根据公钥是无法推导出私钥的；

特点

（1）比对称加密安全：加密和解密是不同的钥匙，非对称加密的私钥是由自己保管不会外泄的，除了自己没有任何人知道私钥，而对称加密只有一把密钥并且通信双方都要知道密钥，一旦密钥知道的人越多那么安全的风险就越大。

（2）更方便可扩展：公钥可以公布在网络中，任何人都可以拿着公钥和你进行通信，而对称加密密钥是不可能公布在网络中的，只能通过私下约定密钥规则。

此时小芳和小明发送信息就会是如下流程：

1、小明把公钥告诉小芳，私钥由自己保存；

2、小芳用小明的公钥加密数据，然后把加密的数据发送给小明。

3、小明接收到小芳的消息后用自己的私钥解密消息。

4、小明再用自己的私钥加密自己需要回复小芳的信息，然后发送给小芳。

5、小芳获取到小明回复的信息后，用小明的公钥解密小明回复过来的信息。

非对称加密的问题

虽然非对称加密很安全，但是和对称加密比起来，它的解密速度非常慢，所以通常会用混合加密的方式进行通信，混合加密是用非对称加密的方式交换双方的对称加密秘钥，交换对称加密秘钥之后再用 对称加密的方式进行通信。

数字签名

信息被篡改的风险

上面的对称加密和非对称加密已经解决了信息传输中的安全问题了，经过加密的数据黑客截取了也无法解密。但是还有一个问题，虽然黑客无法解密通信的内容，但是黑客可以篡改数据双方的通信数据，那么这种情况下我们如何识别数据经过网络传输之后是否被别人篡改过呢，这种情况下就需要用到数字签名了来验证数据是否为对方发出；

使用数字签名流程如下：

这时小芳给小明发送信息需要做4件事：

首先把需要发送的信息进行哈希得到信息摘要;

=>然后对信息内容和摘要进行签名得到数字签名;

=>然后用对称加密秘钥把信息内容和数字签名进行对称加密;

=>最后再把对称加密的秘钥进行加密。

1、小芳发送信息前首先把需要发送的数据用哈希函数计算出一个哈希值出来得到一个信息摘要（不懂技术的人可以把这个哈希值类比成发送内容里面所有字的笔画的总和，只要内容改变那么这个值就会跟着变)，当然这个计算哈希值的过程是不可逆的，无法通过哈希值推导出信息的内容。

2、小芳用自己的私钥对信息摘要进行加密得到一个数字签名（因为私钥加密的数据只有公钥才能解密，如果小明用小芳的公钥能解密到正确的数据，那证明此信息必定是由小芳发出）。

3、小芳然后用“对称秘钥”对加密信息内容和数字签名进行对称加密。

4、最后小芳用小明的公钥对“对称秘钥”进行非对称加密，然后把用加密过后的“对称加密秘钥”，和用对称加密秘钥加密过后的信息内容、数字签名一起发给了小明。

当小明接收到小芳的信息后，小明需要做4件事

1、当小明收到了小芳的信息后，首先用自己的私钥解密得到对称加密的秘钥。

2、然后用对称加密秘钥解密得到信息信息内容和数字签名。

3、然后用小芳的公钥解密数字签名得到信息摘要。

4、最后把信息内容进行哈希得到哈希值与解密过后得到的信息摘要进行比对，如果相同则信息没有被篡改过。

数字证书

身份确认证的问题

数字签名解决了信息可能会被篡改的问题，但是还有另外一个问题就是小明如何确定当前给我发信息的人就是小芳呢？黑客也可以伪装成小芳的身份然把小芳的公钥替换成自己的公钥，这样小明无法分辨出来的。

这样就衍生了一个身份认证的问题，显然这个身份证明不能由当事人自己发出来，只能由一个大家都信任的公开机构**（certificate authority，简称CA）**来发行证书，大家先要到CA去申请一个数字证书（证书信息包括发布机构，所属人，公钥，过期时间等信息）；

最后通讯流程变成下面的情况：

1、小芳首先去CA申请一个数字证书；

2、小芳把信息加密后+加上签名和数字证书发送给小明；

3、小明收到小芳信息后，拿着小芳传过来的数字证书到CA去验证；

4、如果查询到对应数字证书信息里的所属人的确为小芳，那么身份真实可以进行通讯；

5、然后小明根据数字证书信息生成一个专属于小芳和小明加密方式（这里为对称加密），两个人通过此加密方式进行通讯；

请简单说一下你了解的端口及对应的服务

常见状态码及原因短语

HTTP请求结构：请求方式 + 请求URI + 协议及其版本
　　HTTP响应结构：状态码 + 原因短语 + 协议及其版本

1×× : 请求处理中，请求已被接受，正在处理

2×× : 请求成功，请求被成功处理
200 OK

3×× : 重定向，要完成请求必须进行进一步处理
301 : 永久性转移
302 ：暂时性转移
304 ：已缓存

4×× : 客户端错误，请求不合法
400：Bad Request,请求有语法问题
403：拒绝请求
404：客户端所访问的页面不存在

5×× : 服务器端错误，服务器不能处理合法请求
500 ：服务器内部错误
的公钥替换成自己的公钥，这样小明无法分辨出来的。

[外链图片转存中…(img-PB29ZVze-1602738063315)]