1.网络基础HTTP,FTP,UDP,TCP

admin 管理员组

文章数量: 887019

1.网络基础HTTP,FTP,UDP,TCP

1. HTTP与FTP

HTTP,即超文本传输协议的缩写；
FTP,即文件传输协议的简称；
   IP 地址 32bit 全为 0 的地址（0.0.0.0）表示的是本网络本主机，这个 IP 地址在 IP 数据报中只能用作源 IP 地
址，这发生在当设备启动时但又不知道自己的 IP 地址情况下。

2. UDP与TCP

UDP协议特点：
a. 无连接，不可靠。
b. 尽可能提供交付数据服务，出现差错直接丢弃，无反馈。
c. 面向报文，发送方的 UDP 拿到上层数据直接添加个 UDP 首部，然后进行校验后就递交给 IP 层，而接
收的一方在接收到 UDP 报文后简单进行校验，然后直接去除数据递交给上层应用。
d. 支持一对一，一对多，多对一，多对多的交互通信。
e. 速度快，UDP 没有 TCP 的握手、确认、窗口、重传、拥塞控制等机制，UDP 是一个无状态的传输协议，
所以它在传递数据时非常快，即使在网络拥塞的时候 UDP 也不会降低发送的数据。
  UDP 虽然有很多缺点，但是也不排除其能用于很多场合，因为在如今的网络环境下，UDP 协议传输出现错误的概率是很小的，并且它的实时性是非常好，常用于实时视频的传输，比如直播、网络电话等，因为即使是出现了数据丢失的情况，导致视频轻微卡帧,也是可以接受的。
  UDP常用于对传输速度有要求的场合。
  TCP 与 UDP 一样，都是传输层的协议，但是提供的服务却大不相同，UDP 为上层应用提供的是一种不可靠的，无连接的服务，而 TCP 则提供一种面向连接、可靠的字节流传输服务，TCP 让两个主机建立连接的关系，应用数据以数据流的形式进行传输，这与 UDP 协议是不一样：
  UDP 运载的数据是以报文的形式，各个报文在网络中互不相干传输，UDP 每收到一个报文就递交给上层应用，因此如果对于大量数据来说，应用层的重装是非常麻烦的，因为 UDP 报文在网络中到达目标主机的顺序是不一样的；
  而 TCP 采用数据流的形式传输，先后发出的数据在网络中虽然也是互不相干的传输，但是这些数据本身携带的信息却是紧密联系的，TCP 协议会给每个传输的字节进行编号，当然啦，两个主机方向上的数据编号是彼此独立的，在传输的过程中，发送方把数据的起始编号与长度放在 TCP 报文中，在接收方将所有数据按照编号组装起来，然后返回一个确认，当所有数据接收完成后才将数据递交到应用层中。

TCP的特性：
一个TCP连接必须有双非的IP地址与端口号；
TCP发送方发送数据后，启动定时，超时无应答，再重传。
TCP的缓冲机制：
a.数据量小，等凑足够了一起传。
b.发出去的数据，要收到接收成功的应答后才会删去。
c. 接收方也有缓冲机制。

全双工通信

TCP连接建立成功后，两个主机可互发数据，数据是双向流动的，所以其是一个全双工的协议。若其中一个传输方向断掉了，就为半双工通信。

流量控制

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。

如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。
发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

发送方何时再继续发送数据?

可以采用这样的策略：当接收方处理好数据，接受窗口 win > 0 时，接收方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就继续发送数据。

当接收确认报文丢失后，这时候就会引发一个问题：接收方发了通知报文后，继续等待发送方发送数据，而发送方则在等待接收方的通知报文，此时双方会陷入一种僵局。

为了解决这种问题，我们采用了另外一种策略：当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。

一些术语及其注意点说明

1、这里说明下，由于TCP/IP支持全双工传输，因此通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。

2、接收窗口的大小固定吗？
在早期的TCP协议中，接受接受窗口的大小确实是固定的，不过随着网络的快速发展，固定大小的窗口太不灵活了，成为TCP性能瓶颈之一，也就是说，在现在的TCP协议中，接受窗口的大小是根据某种算法动态调整的。

3、接受窗口越大越好吗？
接受窗口如果太小的话，显然这是不行的，这会严重浪费链路利用率，增加丢包率。那是否越大越好呢？答否，当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。

4、发送窗口和接受窗口相等吗？
接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。

差错控制

除了确认与重传之外，TCP 协议也会采用校验和的方式来检验数据的有效性，主机在接收数据的时候，会将重复的报文丢弃，将乱序的报文重组，发现某段报文丢失了会请求发送方进行重发，因此在 TCP 往上层协议递交的数据是顺序的、无差错的完整数据。

拥塞控制

什么是拥塞？当数据从一个大的管道（如一个快速局域网）向一个较小的管道（如一个较慢的广域网）发送时便会发生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞，这种是网络状况的原因。如果一个主机还是以很大的流量给另一个主机发送数据，但是其中间的路由器通道很小，无法承受这样大的数据流量的时候，就会导致拥塞的发生，这样子就导致了接收方无法在超时时间内完成接收（接收方此时完全有能力处理大量数据），而发送方又进行重传，这样子就导致了链路上的更加拥塞，延迟发送方必须实现一直自适应的机制，在网络中拥塞的情况下调整自身的发送速度，这种形式对发送方的控制被称为拥塞控（congestion control），与前面我们说的流量控制是非常相似的，而且 TCP 协议采取的措施也非常相似，均是限制发送方的发送速度。

TCP报文

TCP 报文段由 首部 + 数据区域组成，TCP 报文段的首部我们称之为 TCP 首部，其首部内容很丰富，各个字段都有不一样的含义，如果不计算选项字段（如果为空），一般来说 TCP 首部只有 20 个字节。

每个 TCP 报文段都包含源主机和目标主机的端口号，用于寻找发送端和接收端应用线程，这两个值加上 IP首部中的源 IP 地址和目标 IP 地址就能确定唯一一个 TCP 连接。

序号字段用来标识从 TCP 发送端向 TCP 接收端发送的数据字节流，它的值表示在这个报文段中的第一个数据字节所处位置码，根据接收到的数据区域长度，就能计算出报文最后一个数据所处的序号，因为 TCP 协议会对发送或者接收的数据进行编号（按字节的形式），那么使用序号对每个字节进行计数，就能很轻易管理这些数据。序号是 32 bit 的无符号整数。

TCP连接的建立与终止

连接的建立：

通过“三次握手”来实现，首先服务器先启动，等待客户端向它发送连接请求，然后通过下列步骤完成：

握手1。客户端------>服务器（客户端发送握手请求报文， SYN 标志位会被置为 1）
服务器接收成功，为客户端分配缓存空间。

握手2.服务器------>客户端（服务器发送握手应答报文， SYN 标志位会被置为 1）
客户端接收成功，为服务器分配缓存空间。

握手3.客户端------>服务器（客户端返回应答报文，包含自身窗口大小 ，SYN 标志位会被置为 0）

补充提示：在三次握手的第三个阶段可以在报文段数据区域中携带客户到服务器的数据。在完成握手后，客户端与服务器就建立了连接，同时双方都得到了彼此的窗口大小，序列号等信息，在传输TCP 报文段的时候，每个 TCP 报文段首部的 SYN 标志都会被置 0，因为它只用于发起连接，同步序号。

连接的终止

连接的终止通过“四次握手”（或四次挥手）来实现，因为 TCP 连接是全双工连接的服务，因此每个方向上的连接必须单独关闭。当一端完成它的数据发送任务后就能发送一个 FIN 报文段（可以称之为终止连接请求，其实就是 FIN 标志位被设置为1）来终止这个方向上的连接。

客户端发送一个 FIN 报文段只意味着在这一方向上没有数据流动，一个 TCP 连接在发送一个 FIN后仍能接收数据，但是在实际应用中只有很少的 TCP 应用程序这样做。
挥手1.客户端------>服务器（客户端发送FIN报文，请求终止连接）
挥手2.服务器------>客户端（服务器发送ACK报文，对终止连接的应答），此时断开了客户端到服务器这一方向的连接。
挥手3.服务器------>客户端（服务器发送FIN报文，向应用程序请求关闭与这个客户端的连接，）
挥手4.客户端------>服务器（客户端返回ACK报文来确认终止连接的请求），此时断开了服务器到客户端这一方向的连接。

TCP状态

7个状态：
LISTENING （监听状态）：提供某种服务，侦听远方 TCP 端口的连接请求，当提供的服务没有被连接时，处于LISTENING 状态，端口是开放的，等待被连接。

SYN_SENT (客户端状态)：客户端调用 connect() 函数，将会发送一个 SYN 请求建立一个连接，在发送连接请求后等待匹配的连接请求，此时状态为 SYN_SENT.

SYN_RECEIVED (服务端状态)：在收到和发送一个连接请求后，等待对方对连接请求的确认，当服务器收到客户端发送的同步信号时，将标志位 ACK 和 SYN 置 1 发送给客户端，此时服务器端处于SYN_RCVD 状态，如果连接成功了就变为 ESTABLISHED，正常情况下 SYN_RCVD 状态非常短暂。

ESTABLISHED 状态：这个状态是处于稳定连接状态，建立连接的 TCP 协议两端的主机都是处于这个状态，它们相互知道彼此的窗口大小、序列号、最大报文段等信息。

FIN_WAIT_1 与 FIN_WAIT_2 状态：处于这个状态一般都是单向请求终止连接，然后主机等待对方的回应，而如果对方产生应答，则主机状态转移为FIN_WAIT_2，此时{主机->对方}方向上的TCP连接就断开，但是 {对方-> 主机} 方向上的连接还是存在的。此处有一个注意的地方：如果主机处于 FIN_WAIT_2状态，说明主机已经发出了 FIN 报文段，并且对方也已对它进行确认，除非主机是在实行半关闭状态，否则将等待对方主机的应用层处理关闭连接，因为对方已经意识到它已收到 FIN 报文段，它需要主机发一个 FIN 来关闭 {对方-> 主机} 方向上的连接。只有当另一端的进程完成这个关闭，主机这端才会从FIN_WAIT_2 状态进入 TIME_WAIT 状态。否则这意味着主机这端可能永远保持这个 FIN_WAIT_2 状态，另一端的主机也将处于 CLOSE_WAIT 状态，并一直保持这个状态直到应用层决定进行关闭。

CLOSE-WAIT 状态：等待从本地用户发来的连接中断请求，被动关闭端 TCP 接到 FIN 后，就发出 ACK以回应 FIN 请求 (它的接收也作为文件结束符传递给上层应用程序), 并进入 CLOSE_WAIT.

TIME_WAIT 状态：TIME_WAIT 状态也称为 2MSL 等待状态。每个具体 TCP 连接的实现必须选择一个TCP 报文段最大生存时间 MSL（Maximum Segment Lifetime），如 IP 数据报中的 TTL 字段，表示报文在网络中生存的时间，它是任何报文段被丢弃前在网络内的最长时间，这个时间是有限的，为什么需要等待呢？我们知道 IP 数据报是不可靠的，而 TCP 报文段是封装在 IP 数据报中，TCP 协议必须保证发出的 ACK 报文段是正确被对方接收，因此处于该状态的主机必须在这个状态停留最长时间为 2 倍的MSL，以防最后这个 ACK 丢失，因为 TCP 协议必须保证数据能准确送达目的地。

上图中：
• 虚线：表示服务器的状态转移。
• 实线：表示客户端的状态转移。
• 图中所有“关闭”、“打开”都是应用程序主动处理。
• 图中所有的“超时”都是内核超时处理。

三次握手过程：
• 图中 (7)：服务器的应用程序主动使服务器进入监听状态，等待客户端的连接请求。
• 图中 (1)：首先客户端的应用程序会主动发起连接，发送 SNY 报文段给服务器，在发送之后就进入SYN_SENT 状态等待服务器的 SNY ACK 报文段进行确认，如果在指定超时时间内服务器不进行应答确认，那么客户端将关闭连接。
• 图中 (8)：处于监听状态的服务器收到客户端的连接请求（SNY 报文段），那么服务器就返回一个 SNYACK 报文段应答客户端的应，并且服务器进入 SYN_RCVD 状态。
• 图中 (1)：如果客户端收到了服务器的 SNY ACK 报文段，那么就进入 ESTABLISHED 稳定连接状态，并向服务器发送一个 ACK 报文段。
• 图中 (9)：同时，服务器收到来自客户端的 ACK 报文段，表示连接成功，进入 ESTABLISHED 稳定连接状态，这正是我们建立连接的三次握手过程。

四次挥手过程：
• 图中 (3)：一般来说，都是客户端主动发送一个 FIN 报文段来终止连接，此时客户端从 ESTABLISHED稳定连接状态转移FIN_WAIT_1 状态，并且等待来自服务器的应答确认。
• 图中 (10)：服务器收到 FIN 报文段，知道客户端请求终止连接，那么将返回一个 ACK 报文段到客户端确认终止连接，并且服务器状态由稳定状态转移为 CLOSE_WAIT 等待终止连接状态。
• 图中 (4)：客户端收到确认报文段后，进入 FIN_WAIT_2 状态，等待来自服务器的主动请求终止连接，此时 {客户端-> 服务器} 方向上的连接已经断开。
• 图中 (11)：一般来说，当客户端终止了连接之后，服务器也会终止 {客户端-> 服务器} 方向上的连接，因此服务器的原因程序会主动关闭该方向上的连接，发送一个 FIN 报文段给客户端。
• 图中 (5)：处于 FIN_WAIT_2 的客户端收到 FIN 报文段后，发送一个 ACK 报文段给服务器。
• 图中 (12)：服务器收到 ACK 报文段，就直接关闭，此时 {客户端-> 服务器} 方向上的连接已经终止，进入 CLOSED 状态。
• 图中 (6)：客户端还会等待 2MSL，以防 ACK 报文段没被服务器收到，这就是四次挥手的全部过程。注意：对于图中 (13)(14)(15) 的这些状态都是一些比较特殊的状态，我们暂时就不讲解了，总的来说都是一样的。

参考链接：.html
野火嵌入式linux教程文档

本文标签： 1网络基础HTTP ftp UDP TCP