②A 向 B 发送连接请求报文，首部的同部位SYN=1，ACK=0，随机选择一个初始序号seq=x。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但要消耗一个序号，发送后TCP客户进程进入 SYN-SENT 同步已发送状态。====A向B说：让我们建立连接吧。我发送的信息序号会从x开始。

③B 收到 A 的连接请求报文后，如果同意建立连接，就会向A发送确认。确认报文段中SYN=1，ACK=1，确认号ack=x+1，同时为自己随机选择一个初始序号seq=y,这个报文段也不能携带数据，但同样要消耗一个序号。TCP服务器进程进入 SYN-RCVD 同步收到状态。====B向A说：收到，我已经准备好接受序号为x+1的信息了。我发送的信息序号会从y开始。

④A 收到 B 的确认后，还要对该确认再进行一次确认。确认报文段ACK=1，确认序号ack=y+1，自己的序号seq=x+1。ACK报文段可以携带数据，但不携带数据则不消耗序号。这时，TCP连接已经建立，A 进入 ESTABLISHED 已建立连接状态，B 接收到该报文后也进入 ESTABLISHED 状态，客户端会稍早于服务器端建立连接。====A向B说：好的，我也收到了你的序号了。你可以想问我发送序号为y+1的信息了。

以上连接建立的过程叫三报文握手。

确认号的作用是向对方表示，我期待收到的下一个报文段中的第一个数据字节的序号。如果你向对方回复了 ack = 31, 代表着你已经收到了序号截止到30的数据，期待的下一个数据起点是 31 。

若确认号=N，则表明到序号N-1为止的所有数据都已经正确收到了。

三次握手的原因：

①为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

②三次握手是通信双方相互告知并确认对方已经收到了自己的初始序号值的步骤。TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，也就是seq 和 ack，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

③三次握手才能让双方均确认自己和对方的发送和接收能力都正常。

第一次握手：客户端只是发送出请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；

第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。

TCP 建立连接为什么要三次握手而不是四次？

因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

有一种网络攻击是利用了 TCP 建立连接机制的漏洞，你了解吗？这个问题怎么解决？

答：在三次握手过程中，服务器在收到了客户端的 SYN 报文段后，会分配并初始化连接变量和缓存，并向客户端发送 SYN + ACK 报文段，这相当于是打开了一个“半开连接 (half-open connection)”，会消耗服务器资源。如果客户端正常返回了 ACK 报文段，那么双方可以正常建立连接，否则，服务器在等待一分钟后会终止这个“半开连接”并回收资源。这样的机制为 SYN洪泛攻击 (SYN flood attack)提供了机会，这是一种经典的 DoS攻击 (Denial of Service，拒绝服务攻击)，所谓的拒绝服务攻击就是通过进行攻击，使受害主机或网络不能提供良好的服务，从而间接达到攻击的目的。在 SYN 洪泛攻击中，攻击者发送大量的 SYN 报文段到服务器请求建立连接，但是却不进行第三次握手，这会导致服务器打开大量的半开连接，消耗大量的资源，最终无法进行正常的服务。

解决方法：SYN Cookies，现在大多数主流操作系统都有这种防御系统。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。它的原理是，在服务器接收到 SYN 报文段并返回 SYN + ACK 报文段时，不再打开一个半开连接，也不分配资源，而是根据这个 SYN 报文段的重要信息 (包括源和目的 IP 地址，端口号可一个秘密数)，利用特定散列函数计算出一个 cookie 值。这个 cookie 作为将要返回的SYN + ACK 报文段的初始序列号(ISN)。当客户端返回一个 ACK 报文段时，服务器根据首部字段信息计算 cookie，与返回的确认序号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后分配资源并建立连接，否则拒绝建立连接。

四次挥手

四次挥手详细过程如下：

客户端发送连接释放报文段，终止控制位FIN置1，请求关闭连接，并停止发送数据。序号字段 seq = x (它等于之前已发送过的所有数据的最后一个字节的序号加1)，然后客户端会进入终止等待1（FIN-WAIT-1）状态，等待服务器的确认报文。TCP规定，FIN报文段即使不携带数据，它也要消耗一个序号。
服务器收到连接释放报文段后，发出确认报文，ACK = 1，确认号ack = x + 1，并带上自己的序号 seq = y，然后服务器就进入关闭等待（CLOSE-WAIT）状态。TCP服务器进程还会通知上层的应用程序：对方已经释放连接，此时TCP连接处于半关闭状态，也就是说客户端已经没有数据要发送了，但是服务器还可以发送数据，客户端也还能够接收。
客户端收到服务器的 ACK 报文段后随即进入终止等待2（FIN-WAIT-2）状态，此时还能收到来自服务器的数据，直到收到服务器的连接释放报文段。
服务器发送完所有数据后，会向客户端发送连接释放报文段。FIN=1,服务器必须重复上次已发送过的确认号ack=x+1，seq=z。随后服务器进入最后确认（LAST-ACK）状态，等待客户端的确认报文段。
客户端收到来自服务器的连接释放报文段后，向服务器发送确认报文段，ACK=1，确认号ack=z+1，序号seq=x+1。随后进入时间等待（TIME-WAIT）状态，此时，TCP连接还没有释放掉。必须经过2MSL(2 * Maximum Segment Lifetime，两倍的最大报文段寿命)后，客户端才进入CLOSED状态。
服务器在接收到客户端的确认报文段后，就进入 CLOSED 状态。服务器撤销传输控制块TCB后，就结束了这次TCP连接。由于没有等待时间，一般而言，服务器比客户端更早进入 CLOSED 状态。

为什么 TCP 关闭连接为什么要四次而不是三次？

答：服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段，接下来可能会继续发送数据，在数据发送完后，服务器会向客户端发送 FIN 报文，表示数据已经发送完毕，请求关闭连接，然后客户端再做出应答，因此一共需要四次挥手。

客户端为什么需要在 TIME-WAIT 状态等待 2MSL 时间才能进入 CLOSED 状态？

答：

①为了保证客户端发送的最后一个ACK报文段能够到达服务器。这个ACK报文段可能丢失，使处于最后确认状态的服务器收不到对已发送的FIN+ACK报文段的确认。服务器就会超时重传这个FIN+ACK报文段。客户端如果在2MSL时间内收到这个重传的FIN+ACK报文段，就会重传一次确认，重新启动2MSL计时器。MSL是任何报文段在网络上存在的最长时间，超过这个时间的报文将被丢弃。如果在2MSL这段时间内没有收到来自服务器的 FIN+ACK报文段，那就说明服务器已经成功收到了 ACK 报文段。最后，客户端和服务器都正常进入到CLOSED状态。如果客户端在发送完ACK报文段后立即释放连接，那么就无法收到服务器重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样服务器就无法正常进入CLOSED状态。

②为了让本连接持续时间内所产生的所有报文段都从网络中消失，使得下一个新的连接中不会出现旧的连接请求报文段。

拥塞控制和流量控制

流量控制

流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

TCP报文段发送时机的三种控制机制：

①TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。

②由发送方的应用进程指明要求发送报文段，即TCP支持的推送操作

③发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去。

拥塞控制的原理

在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况叫做拥塞。拥塞问题的实质往往是整个系统的各个部分不匹配。只有所有的部分都平衡了，问题才会得到解决。

拥塞控制和流量控制的差别

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制的四种算法，

即慢开始（Slow-start)、拥塞避免（Congestion Avoidance)、快重传（Fast Restrangsmit)和快回复（Fast Recovery）。我们假定：1）数据是单方向传送，而另外一个方向只传送确认。2）接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去，提高网络利用率。但是只要网络出现拥塞，拥塞窗口就必须减小一些，以减少注入到网络的分组数。

拥塞窗口 (congestion window，简写为 cwnd)的概念：

拥塞窗口是由发送方根据网络状况维护的一个变量，用于控制自己的数据发送速率。前文提到了发送方的发送窗口受两个变量约束，一是接收方通告的窗口大小值，二就是发送方自身的拥塞窗口，实际的发送窗口大小取二者最小值。

慢开始算法思路：

由小到大逐渐增大发送窗口（拥塞窗口数值）。具体是，当新建连接时，cwnd初始化为1个最大报文段(MSS)，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS。用这样的方法来逐步增大拥塞窗口。“慢”指在TCP开始发送报文段时先设置cwnd=1，使发送方在开始时只发送一个报文段（试探网络拥塞情况），然后逐渐增大cwnd。

拥塞避免算法思路：

让拥塞窗口缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。这样拥塞窗口按线性规律缓慢增大，具有加法增大的特点。拥塞避免并非完全能够避免拥塞，是指将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

为了防止 cwnd 增长过大引起网络拥塞，设置一个慢开始门限(slow start threshold，简写为 ssthresh)，初始值为16 ，

当cnwd < ssthresh，使用慢开始算法
当 cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
当 cnwd > ssthresh，使用拥塞避免算法

快重传算法

可以让发送方尽早知道发生了个别报文段的丢失。该算法要求接收方立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。规定，发送方只要一连收到3个重复确认，就知道接收方确实没有收到某个报文段，因而应当立即进行重传。这样就不会出现超时，发送方就不会误认为出现了网络拥塞。

快重传和快恢复配套使用。执行快恢复算法后，调整门限值ssthresh=cwnd/2,设置拥塞窗口cwnd= ssthresh，并开始执行拥塞避免算法。

AIMD算法：AI指在拥塞避免阶段，拥塞窗口按线性规律增大。MD是指一旦出现超时或3个重复确认，就把门限值设置为当前拥塞窗口值的一半，并大大减小拥塞窗口的数值。

TCP 滑动窗口

利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。

我们可以把发送方的发送缓存中的字节分为以下四类，每个编号对应一个字节：

第一类：已发送且已确认，这些数据已经发送成功并已经被确认的数据，比如图中的前31个bytes，这些数据其实的位置是在窗口之外了，下一步将被移出发送缓存。窗口内顺序最低的字节被确认之后，窗口左边界会向右移动，称为窗口合拢。

第二类：已发送但未收到确认，这部分数据已经被发送出去，但是还没有收到接收端的 ACK，认为并没有完成发送，这部分数据属于窗口内的数据。

第三类：未发送但是接收方已经准备好接收，这部分是尽快发送的数据，这部分数据已经被加载到缓存中，也在发送窗口中，正在等待发送，其实这个窗口是完全有接收方告知的，接收方告知当前可以接受这些数据，所以发送方需要尽快的发送。

第四类：未发送且接收方未准备好接收，这些数据属于未发送，同时接收端也不允许发送的，因为这些数据已经超出了发送端所接收的范围。

发送窗口：图中的黑色框就是发送方的发送窗口，其大小由两个因素决定：1、接收方的提供的窗口大小 (TCP 报文段首部中的 window 字段)，发送方在三次握手阶段首次得到这个值，之后的通信过程中接收方会根据自己的可用缓存对这个值进行动态调整；2、发送方会根据网络情况维护一个拥塞窗口变量 (后文介绍)。发送窗口的大小取这两个值的最小值。对于发送方来说，发送窗口分为两部分，分别是已经发送的部分（已经发送了，但是没有收到ACK）和可用窗口，接收端允许发送但是没有发送的那部分称为可用窗口。

接收窗口：对于接收端也是有一个接收窗口的，类似发送端，接收端的数据有3个分类，因为接收端并不需要等待ACK所以它没有类似的接收并确认了的分类，情况如下

Received and ACK Not Send to Process：这部分数据属于接收了数据但是还没有被上层的应用程序接收；
Received Not ACK: 已经接收，但是还没有回复 ACK；
Not Received：有空位，还没有被接收的数据。

滑动窗口是如何滑动的？

滑动窗口的滑动过程

累积确认概念：TCP 并不是每一个报文段都会回复一个 ACK ，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送 1 个 ACK，这称为累积确认。比如说发送方有 1/2/3 3 个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候 2/3 报文段就只能放在缓存中等待报文1的空洞被填上，如果报文段1一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个 ACK 对第3个报文段进行确认，就代表对这三个报文段全部进行了确认。

下面举例说明一下窗口滑动的过程：

在握手过程中，接收方通告的窗口大小为20字节，所以发送方将发送窗口大小设置为20字节。
从图中的"上一个发送窗口的位置"(灰色虚线框)说起， 32-51号字节恰好处于发送窗口中，恰好20个字节，假设 TCP 将其分为 4 个报文段进行发送，每个报文段 5 个字节数据，分别记为 seg1 32-36, seg2 37-41, seg3 42-46, seg4 47-51。
TCP 将有序发送 seg1、seg2、seg3和seg4四个报文段，如果这四个报文段都顺利到达接收方 (图中并不是这样)，接收方将发回一个累积确认的 ACK 报文段，其中 ack = 52，代表希望收到下一个报文段的起始字节编号，报文段中也会继续通告窗口大小，如果还是20字节，那么发送方的窗口将整体向右移动20字节，如果通告的窗口值变小，比如变成15，那么发送窗口左边界移动20字节，右边界移动15字节。
如果在发送过程中 seg2 报文段丢失，而其他三个报文段正常到达接收方，那么接收方会先接受这三个报文段，然后返回 ACK 报文段，ack = 37，表示希望收到的下一个报文段的起始字节号为37，也就是seg2报文段。如果通告窗口值未发生变化，发送方在收到 ACK 后会将窗口整体右移5个字节，也就变成了图中的位置。
由于 seg2 还未收到 ACK，当重传计时器超时后，发送方会重新发送 seg2，此时52-56号字节又落到了发送窗口中，TCP 将其封装成报文段进行发送，如果接收方全部顺利收到，会返回一个累积确认的 ACK，ack = 57，表示希望收到的下一个报文段的起始字节号为57。

接下来就是重复上述过程，直到 TCP 字节流的所有数据发送完毕。在这个过程中，接收方会根据自己接收缓存的剩余空间动态调整窗口值，对发送方进行流量控制。

TCP 粘包和拆包的原因

TCP 是以字节流的方式传输数据，传输的最小单位为一个报文段（segment）。TCP 首部中有个选项 (Options)的字段，常见的选项为 MSS (Maximum Segment Size最大消息长度)，它是收发双方协商通信时每一个报文段所能承载的最大有效数据的长度。数据链路层每次传输的数据有个最大限制MTU (Maximum Transmission Unit)，一般是1500字节，超过这个量要分成多个报文段，MSS 则是这个最大限制减去 TCP 的首部，光是要传输的数据的大小，一般为1460字节。

MSS = MTU - Header

TCP 为提高性能，发送端会将需要发送的数据发送到发送缓存，等待缓存满了之后，再将缓存中的数据发送到接收方。同理，接收方也有接收缓存这样的机制，来接收数据。

TCP 粘包和拆包出现的原因：

TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

发生TCP粘包或拆包有很多原因，现列出常见的几点：

要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
应用程序写入数据小于剩余缓存大小，网卡将应用多次写入的数据先缓存起来，然后一起发送到网络上，这将会发生粘包。
接收数据端的应用层没有及时读取接收缓存中的数据，将发生粘包。

TCP 粘包和拆包的解决方案

解决问题的关键在于如何给每个数据包添加边界信息。

1、发送端在每个数据包的包首部中添加数据包的长度信息，这样接收端在接收到数据包后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据，就自然而然的把每个数据包拆分开来。

3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

TCP

TCP 的三个重要特性——

1. 面向连接；面向连接意味着两个使用 TCP 的应用 (通常是一个客户端和一个服务器) 在彼此交换数据之前必须先建立一个 TCP 连接。

2. 基于字节流；TCP 连接双方的数据交换格式是以字节 (byte，1byte = 8 bit）构成的有序但无结构的字节流。

3. 可靠性。它主要通过以下方式确保可靠性。

合理的数据大小：TCP 发送的数据并不是固定的大小，而是会根据实际情况调整报文段的大小。
检验和：发送端按照特定算法计算出 TCP 报文段的检验和并存储在 TCP 首部中的对应字段上，接收端在接收时会以同样的方式计算校验和，如果不一致，说明报文段出现错误，会将其丢弃。
序号与确认序号：对乱序的数据进行排序后发给应用层，并丢弃重复的数据。
超时重传机制：当 TCP 发出一个报文段后，它会启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
连接管理：也就是三次握手和四次挥手，连接的可靠性是整体可靠性的前提，本文第二部分将会详细介绍连接管理的内容。
流量控制：TCP 双方都有固定大小的缓冲区，流量控制的原理是利用滑动窗口控制数据发送速度，避免缓冲区溢出导致数据丢失。
拥塞控制：TCP 利用慢启动和拥塞避免等算法实现了拥塞控制。

TCP报文段的组成：

序号 (Sequence Number)：这个字段的主要作用是用于将失序的数据重新排列。TCP 会隐式地对字节流中的每个字节进行编号，而 TCP 报文段的序号被设置为其数据部分的第一个字节的编号。序号是 32 bit 的无符号数，取值范围是0到 232 - 1。
确认序号 (Acknowledgment Number)：接收方在接受到数据后，会回复确认报文，其中包含确认序号，作用就是告诉发送方自己接收到了哪些数据，下一次数据从哪里开始发。假设ack=201，表示序号为201之前的数据已经收到，现在期望接收序号为201及之后的数据。因此，确认序号应当是上次已成功收到数据字节序号加 1。只有 ACK 标志为 1 时确认序号字段才有效。
控制位 (Control Bits)：在三次握手和四次挥手中会经常看到 SYN、ACK 和 FIN 的身影，一共有 6 个标志位，它们表示的意义如下：①ACK (Acknowledgment Bit)：值为 1 时，确认序号生效。②PSH (Push Bit)：接收方应尽快将这个报文段交给应用层。③SYN (Synchronize Bit)：同步序号，用于发起一个连接。④FIN (Finish Bit)：发送端要求关闭连接。⑤URG (Urgent Bit)：值为 1 时，紧急指针生效。⑥RST (Reset Bit)：发送端遇到问题，想要重建连接。
窗口大小 (Window)： TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个 16 bit 字段，单位是字节，因而窗口大小最大为 65535 字节。
检验和 (Checksum)：功能类似于数字签名，用于验证数据完整性，也就是确保数据未被修改。检验和覆盖了整个 TCP 报文段，包括 TCP 首部和 TCP 数据，发送端根据特定算法对整个报文段计算出一个检验和，接收端会进行计算并验证。
有效数据部分 (Data)：这部分也不是必须的，比如在建立和关闭 TCP 连接的阶段，双方交换的报文段就只包含 TCP 首部。

OSI七层模型和TCP五层模型

OSI定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）。

应用层是最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。它解决了通过应用进程间的交互来实现特定网络应用的问题。常见应用层的协议有：HTTP，HTTPS，FTP，POP3、SMTP等。所有能和用户交互产生网络流量的程序。

表示层：该层的功能为数据格式转换、数据压缩和恢复、数据加密解密。它解决了通信双方交换信息的表示问题。

会话层：该层的功能为①建立、管理、终止会话。②使用校验点可使会话在通信失效时从校验点继续恢复通信，实现数据同步。它解决了进程之间进行会话的问题。

传输层（运输层）：负责向两个主机中进程之间的通信提供通用的数据传输服务。该层的功能为①提供可靠传输、不可靠传输。②差错控制。③流量控制。④复用分用。复用：多个应用层进程可同时使用运输层的服务。分用：运输层把收到的信息分别交付上面应用层中的相应进程。它解决了进程之间基于网络的通信问题。

网络层（IP层、网际层）：负责选择合适的路由，把分组从源端传到目的端，为分组交换网上的不同主机提供通信服务。该层的功能为路由控制、流量控制、差错控制、拥塞控制。它解决了分组在多个网络之间传输的问题。

数据链路层：负责把网络层传下来的数据报组成帧。它解决了帧在一个网络上传输的问题。它的功能：成帧、差错控制、流量控制、访问控制。

物理层：负责在物理媒体上实现比特流的透明传输。它解决了使用何种信号来传输比特0和1的问题。它的功能有定义接口特性、定义传输模式、定义传输速率、比特同步、比特编码。

TCP对应的应用层协议

FTP：文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。

Telnet：远程终端协议，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。

SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。

POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

HTTP：超文本传输协议。负责服务器与浏览器之间的通信。

UDP对应的应用层协议

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。

SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

HTTP和HTTPS

http协议全称是HyperTest Transfer Protocol，超文本传输协议，对客户端和服务器端之间数据传输的格式规范。超文本传输协议（HTTP）是一个用于传输超媒体文档（例如 html）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。

HTTP 是无状态协议。无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。每个请求都是独立的。这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。

HTTP协议的无状态性带来的问题：①用户登录后，切换到其他界面，进行操作，服务器端是无法判断是哪个用户登录的。每次进行页面跳转的时候，得重新登录。②如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。

解决方案：Cookie和session。cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

http报文就是client和server通信时依据http协议，将传输的信息以文本的形式呈现，这个文本就是http报文。http报文分为请求报文和消息报文，这两类报文有着相同的结构组成。

请求报文：

请求行=请求方法+URL+HTTP协议版本，3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。

请求头部由键值对组成，每行一对，格式为“属性名:属性值”。请求头部通知服务器有关于客户端请求的信息。

请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

请求体是报文体，它将页面表单中的数据通过param1=value1¶m2=value2的键值对形式编码成一个格式化串，承载多个请求参数的数据。

https://blog.csdn.net/lzghxjt/article/details/99233637

请求头常见属性：

1) HOST

请求头指明了请求将要发送到的服务器主机名和端口号。

如果没有包含端口号，会自动使用被请求服务的默认端口（比如HTTPS URL使用443端口，HTTP URL使用80端口）。

HTTP、HTTPS等常用的默认端口号

2) Connection

客户端或服务端用来告诉对方当前tcp连接的状态，表示是否需要持续连接。

Connection:keep-alive 网络连接就是持久的，不会关闭，使得对同一个服务器的请求可以继续在该连接上完成。Connection:close 在响应结束后关闭连接，这是HTTP/1.0请求的默认值

3) pragma

Pragma 是一个在 HTTP/1.0 中规定的通用首部，这个首部的效果依赖于不同的实现，所以在“请求-响应”链中可能会有不同的效果。它用来向后兼容只支持 HTTP/1.0 协议的缓存服务器，那时候 HTTP/1.1 协议中的 Cache-Control 还没有出来。

注意：由于 Pragma 在 HTTP 响应中的行为没有确切规范，所以不能可靠替代 HTTP/1.1 中通用首部 Cache-Control，尽管在请求中，假如 Cache-Control 不存在的话，它的行为与 Cache-Control: no-cache 一致。建议只在需要兼容 HTTP/1.0 客户端的场合下应用 Pragma 首部。

4) Cache-Control

对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个属性达到目的。

Cache-Control: no-cache 在发布缓存副本之前，强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证)。

6) User-Agent

用户代理：简称UA。内容是发出请求的用户信息，使得服务器能够识别客户端使用的操作系统及版本、CPU类型、浏览器及版本、浏览器渲染引擎、浏览器语言、插件等。服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送。

7）Accept

请求报文可通过一个“Accept”报文头属性告诉服务端，客户端接受什么类型的响应。
如下报文头相当于告诉服务端，客户端能够接受的响应类型仅为纯文本数据

Accept:text/plain

通配符 * 代表任意类型。如下代表浏览器可以处理所有类型

Accept: */*

Accept属性的值可以为一个或多个MIME类型的值（描述消息内容类型的因特网标准，消息能包含文本、图像、音频、视频以及其他应用程序专用的数据）

常用的Accept属性

8) Referer
表示这个请求是从哪个URL发过来的，假如你通过百度搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是 https://www.baidu.com/

Referer的作用：1.防盗链。2.防止恶意请求。

空 Referer 的定义为， Referer 头部的内容为空，或者，一个 HTTP 请求中根本不包含 Referer 头部。当一个请求并不是由链接触发产生的，那么就不需要指定这个请求的链接来源。比如，直接在浏览器的地址栏中输入一个资源的URL地址，那么这种请求是不会包含 Referer 字段的，因为这是一个“凭空产生”的 HTTP 请求，并不是从一个地方链接过去的。

9) Accept-Encoding

客户端用来

以上是关于学习笔记之计算机网络的主要内容，如果未能解决你的问题，请参考以下文章

python全栈学习笔记网络基础之网络协议篇

Docker学习笔记之网络篇

学习笔记之计算机网络

TCP/IP学习笔记之IP协议

神经网络与深度学习笔记 Chapter 6之卷积神经网络

Andrew Ng机器学习课程笔记之神经网络