计算机网络

重点在TCP/IP协议和HTTP协议。

目录

内容

网络层(IP)

待补充

传输层(TCP/UDP)

1. ISO七层模型中表示层和会话层功能是什么？

   • 表示层：图像、视频编码解，数据加密。

   • 会话层：建立会话，如session认证、断点续传。

2. 描述TCP头部？

   • 序号（32bit）：传输方向上字节流的字节编号。初始时序号会被设置一个随机的初始值（ISN），之后每次发送数据时，序号值 = ISN + 数据在整个字节流中的偏移。假设A -> B且ISN = 1024，第一段数据512字节已经到B，则第二段数据发送时序号为1024 + 512。用于解决网络包乱序问题。

   • 确认号（32bit）：接收方对发送方TCP报文段的响应，其值是收到的序号值 + 1。

   • 首部长（4bit）：标识首部有多少个4字节 * 首部长，最大为15，即60字节。

   • 标志位（6bit）：

     • URG：标志紧急指针是否有效。

     • ACK：标志确认号是否有效（确认报文段）。用于解决丢包问题。

     • PSH：提示接收端立即从缓冲读走数据。

     • RST：表示要求对方重新建立连接（复位报文段）。

     • SYN：表示请求建立一个连接（连接报文段）。

     • FIN：表示关闭连接（断开报文段）。

   • 窗口（16bit）：接收窗口。用于告知对方（发送方）本方的缓冲还能接收多少字节数据。用于解决流控。

   • 校验和（16bit）：接收端用CRC检验整个报文段有无损坏。

3. 三次握手过程？

   • 第一次：客户端发含SYN位，SEQ_NUM = S的包到服务器。（客 -> SYN_SEND）

   • 第二次：服务器发含ACK，SYN位且ACK_NUM = S + 1，SEQ_NUM = P的包到客户机。（服 -> SYN_RECV）

   • 第三次：客户机发送含ACK位，ACK_NUM = P + 1的包到服务器。（客 -> ESTABLISH，服 -> ESTABLISH）

4. 四次挥手过程？

   • 第一次：客户机发含FIN位，SEQ = Q的包到服务器。（客 -> FIN_WAIT_1）

   • 第二次：服务器发送含ACK且ACK_NUM = Q + 1的包到服务器。（服 -> CLOSE_WAIT，客 -> FIN_WAIT_2）

     • 此处有等待

   • 第三次：服务器发送含FIN且SEQ_NUM = R的包到客户机。（服 -> LAST_ACK，客 -> TIME_WAIT）

     • 此处有等待

   • 第四次：客户机发送最后一个含有ACK位且ACK_NUM = R + 1的包到客户机。（服 -> CLOSED）

5. 为什么握手是三次，挥手是四次？

   • 对于握手：握手只需要确认双方通信时的初始化序号，保证通信不会乱序。（第三次握手必要性：假设服务端的确认丢失，连接并未断开，客户机超时重发连接请求，这样服务器会对同一个客户机保持多个连接，造成资源浪费。）

   • 对于挥手：TCP是双工的，所以发送方和接收方都需要FIN和ACK。只不过有一方是被动的，所以看上去就成了4次挥手。

6. TCP连接状态？

   • CLOSED：初始状态。

   • LISTEN：服务器处于监听状态。

   • SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。

   • SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。

   • ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。

   • FIN_WAIT_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。

   • CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。

   • FIN_WAIT_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN_WAIT_2状态。

   • LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。

   • TIME_WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME_WAIT状态。

7. 解释FIN_WAIT_2，CLOSE_WAIT状态和TIME_WAIT状态？

   • FIN_WAIT_2：

     • 半关闭状态。

     • 发送断开请求一方还有接收数据能力，但已经没有发送数据能力。

   • CLOSE_WAIT状态：

     • 被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。

     • 被动关闭连接一方如果还有剩余数据要发送就会进入CLOSED_WAIT状态。

   • TIME_WAIT状态：

     • 又叫2MSL等待状态。

     • 如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。所以TIME_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。

     • 在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。

8. 解释RTO，RTT和超时重传？

   • 超时重传：发送端发送报文后若长时间未收到确认的报文则需要重发该报文。可能有以下几种情况：

     • 发送的数据没能到达接收端，所以对方没有响应。

     • 接收端接收到数据，但是ACK报文在返回过程中丢失。

     • 接收端拒绝或丢弃数据。

   • RTO：从上一次发送数据，因为长期没有收到ACK响应，到下一次重发之间的时间。就是重传间隔。

     • 通常每次重传RTO是前一次重传间隔的两倍，计量单位通常是RTT。例：1RTT，2RTT，4RTT，8RTT......

     • 重传次数到达上限之后停止重传。

   • RTT：数据从发送到接收到对方响应之间的时间间隔，即数据报在网络中一个往返用时。大小不稳定。

9. 流量控制原理？

   • 目的是接收方通过TCP头窗口字段告知发送方本方可接收的最大数据量，用以解决发送速率过快导致接收方不能接收的问题。所以流量控制是点对点控制。

   • TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗和接收窗。

     • 发送窗：用来限制发送方可以发送的数据大小，其中发送窗口的大小由接收端返回的TCP报文段中窗口字段来控制，接收方通过此字段告知发送方自己的缓冲（受系统、硬件等限制）大小。

     • 接收窗：用来标记可以接收的数据大小。

   • TCP是流数据，发送出去的数据流可以被分为以下四部分：已发送且被确认部分 | 已发送未被确认部分 | 未发送但可发送部分 | 不可发送部分，其中发送窗 = 已发送未确认部分 + 未发但可发送部分。接收到的数据流可分为：已接收 | 未接收但准备接收 | 未接收不准备接收。接收窗 = 未接收但准备接收部分。

   • 发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗口。

10. 拥塞控制原理？

    • 拥塞控制目的是防止数据被过多注网络中导致网络资源（路由器、交换机等）过载。因为拥塞控制涉及网络链路全局，所以属于全局控制。控制拥塞使用拥塞窗口。

    • TCP拥塞控制算法：

      • 慢开始 & 拥塞避免：先试探网络拥塞程度再逐渐增大拥塞窗口。每次收到确认后拥塞窗口翻倍，直到达到阀值ssthresh，这部分是慢开始过程。达到阀值后每次以一个MSS为单位增长拥塞窗口大小，当发生拥塞（超时未收到确认），将阀值减为原先一半，继续执行线性增加，这个过程为拥塞避免。

      • 快速重传 & 快速恢复：略。

      • 最终拥塞窗口会收敛于稳定值。

11. 如何区分流量控制和拥塞控制？

    • 流量控制属于通信双方协商；拥塞控制涉及通信链路全局。

    • 流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。

    • 实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。

12. TCP如何提供可靠数据传输的？

    • 建立连接（标志位）：通信前确认通信实体存在。

    • 序号机制（序号、确认号）：确保了数据是按序、完整到达。

    • 数据校验（校验和）：CRC校验全部数据。

    • 超时重传（定时器）：保证因链路故障未能到达数据能够被多次重发。

    • 窗口机制（窗口）：提供流量控制，避免过量发送。

    • 拥塞控制：同上。

13. TCP soctet交互流程？

    • 服务器：

      • 创建socket -> int socket(int domain, int type, int protocol);

        • domain：协议域，决定了socket的地址类型，IPv4为AF_INET。

        • type：指定socket类型，SOCK_STREAM为TCP连接。

        • protocol：指定协议。IPPROTO_TCP表示TCP协议，为0时自动选择type默认协议。

      • 绑定socket和端口号 -> int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

        • sockfd：socket返回的套接字描述符，类似于文件描述符fd。

        • addr：有个sockaddr类型数据的指针，指向的是被绑定结构变量。

            // IPv4的sockaddr地址结构
            struct sockaddr_in {
                sa_family_t sin_family;    // 协议类型，AF_INET
                in_port_t sin_port;    // 端口号
                struct in_addr sin_addr;    // IP地址
            };
            struct in_addr {
                uint32_t s_addr;
            }
        

        • addrlen：地址长度。

      • 监听端口号 -> int listen(int sockfd, int backlog);

        • sockfd：要监听的sock描述字。

        • backlog：socket可以排队的最大连接数。

      • 接收用户请求 -> int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

        • sockfd：服务器socket描述字。

        • addr：指向地址结构指针。

        • addrlen：协议地址长度。

        • 注：一旦accept某个客户机请求成功将返回一个全新的描述符用于标识具体客户的TCP连接。

      • 从socket中读取字符 -> ssize_t read(int fd, void *buf, size_t count);

        • fd：连接描述字。

        • buf：缓冲区buf。

        • count：缓冲区长度。

        • 注：大于0表示读取的字节数，返回0表示文件读取结束，小于0表示发生错误。

      • 关闭socket -> int close(int fd);

        • fd：accept返回的连接描述字，每个连接有一个，生命周期为连接周期。

        • 注：sockfd是监听描述字，一个服务器只有一个，用于监听是否有连接；fd是连接描述字，用于每个连接的操作。

    • 客户机：

      • 创建socket -> int socket(int domain, int type, int protocol);

      • 连接指定计算机 -> int connect(int sockfd, struct sockaddr* addr, socklen_t addrlen);

        • sockfd客户端的sock描述字。

        • addr：服务器的地址。

        • addrlen：socket地址长度。

      • 向socket写入信息 -> ssize_t write(int fd, const void *buf, size_t count);

        • fd、buf、count：同read中意义。

        • 大于0表示写了部分或全部数据，小于0表示出错。

      • 关闭oscket -> int close(int fd);

        • fd：同服务器端fd。

应用层(HTTP)

HTTP协议工作在应用层，端口号是80。HTTP协议被用于网络中两台计算机间的通信，相比于TCP/IP这些底层协议，HTTP协议更像是高层标记型语言，浏览器根据从服务器得到的HTTP响应体中分别得到报文头，响应头和信息体（HTML正文等），之后将HTML文件解析并呈现在浏览器上。同样，我们在浏览器地址栏输入网址之后，浏览器相当于用户代理帮助我们组织好报文头，请求头和信息体（可选），之后通过网络发送到服务器，，服务器根据请求的内容准备数据。所以如果想要完全弄明白HTTP协议，你需要写一个浏览器 + 一个Web服务器，一侧来生成请求信息，一侧生成响应信息。

从网络分层模型来看，HTTP工作在应用层，其在传输层由TCP协议为其提供服务。所以可以猜到，HTTP请求前，客户机和服务器之间一定已经通过三次握手建立起连接，其中套接字中服务器一侧的端口号为HTTP周知端口80。在请求和传输数据时也是有讲究的，通常一个页面上不只有文本数据，有时会内嵌很多图片，这时候有两种选择可以考虑。一种是对每一个文件都建立一个TCP连接，传送完数据后立马断开，通过多次这样的操作获取引用的所有数据，但是这样一个页面的打开需要建立多次连接，效率会低很多。另一种是对于有多个资源的页面，传送完一个数据后不立即断开连接，在同一次连接下多次传输数据直至传完，但这种情况有可能会长时间占用服务器资源，降低吞吐率。上述两种模式分别是HTTP 1.0和HTTP 1.1版本的默认方式，具体是什么含义会在后面详细解释。

HTTP工作流程

一次完整的HTTP请求事务包含以下四个环节：

• 建立起客户机和服务器连接。

• 建立连接后，客户机发送一个请求给服务器。

• 服务器收到请求给予响应信息。

• 客户端浏览器将返回的内容解析并呈现，断开连接。

HTTP协议结构

请求报文

对于HTTP请求报文我们可以通过以下两种方式比较直观的看到：一是在浏览器调试模式下（F12）看请求响应信息，二是通过wireshark或者tcpdump抓包实现。通过前者看到的数据更加清晰直观，通过后者抓到的数据更真实。但无论是用哪种方式查看，得到的请求报文主题体信息都是相同的，对于请求报文，主要包含以下四个部分，每一行数据必须通过"\r\n"分割，这里可以理解为行末标识符。

• 报文头（只有一行）

  结构：method uri version

  • method

    HTTP的请求方法，一共有9中，但GET和POST占了99%以上的使用频次。GET表示向特定资源发起请求，当然也能提交部分数据，不过提交的数据以明文方式出现在URL中。POST通常用于向指定资源提交数据进行处理，提交的数据被包含在请求体中，相对而言比较安全些。

  • uri

    用来指代请求的文件，≠URL。

  • version

    HTTP协议的版本，该字段有HTTP/1.0和HTTP/1.1两种。

• 请求头（多行）

  在HTTP/1.1中，请求头除了Host都是可选的。包含的头五花八门，这里只介绍部分。

  • Host：指定请求资源的主机和端口号。端口号默认80。

  • Connection：值为keep-alive和close。keep-alive使客户端到服务器的连接持续有效，不需要每次重连，此功能为HTTP/1.1预设功能。

  • Accept：浏览器可接收的MIME类型。假设为text/html表示接收服务器回发的数据类型为text/html，如果服务器无法返回这种类型，返回406错误。

  • Cache-control：缓存控制，Public内容可以被任何缓存所缓存，Private内容只能被缓存到私有缓存，non-cache指所有内容都不会被缓存。

  • Cookie：将存储在本地的Cookie值发送给服务器，实现无状态的HTTP协议的会话跟踪。

  • Content-Length：请求消息正文长度。

  另有User-Agent、Accept-Encoding、Accept-Language、Accept-Charset、Content-Type等请求头这里不一一罗列。由此可见，请求报文是告知服务器请求的内容，而请求头是为了提供服务器一些关于客户机浏览器的基本信息，包括编码、是否缓存等。

• 空行（一行）

• 可选消息体（多行）

响应报文

响应报文是服务器对请求资源的响应，通过上面提到的方式同样可以看到，同样地，数据也是以"\r\n"来分割。

• 报文头（一行）

  结构：version status_code status_message

  • version

    描述所遵循的HTTP版本。

  • status_code

    状态码，指明对请求处理的状态，常见的如下。

    • 200：成功。

    • 301：内容已经移动。

    • 400：请求不能被服务器理解。

    • 403：无权访问该文件。

    • 404：不能找到请求文件。

    • 500：服务器内部错误。

    • 501：服务器不支持请求的方法。

    • 505：服务器不支持请求的版本。

  • status_message

    显示和状态码等价英文描述。

• 响应头（多行）

  这里只罗列部分。

  • Date：表示信息发送的时间。

  • Server：Web服务器用来处理请求的软件信息。

  • Content-Encoding：Web服务器表明了自己用什么压缩方法压缩对象。

  • Content-Length：服务器告知浏览器自己响应的对象长度。

  • Content-Type：告知浏览器响应对象类型。

• 空行（一行）

• 信息体（多行）

  实际有效数据，通常是HTML格式的文件，该文件被浏览器获取到之后解析呈现在浏览器中。

CGI与环境变量

• CGI程序

  服务器为客户端提供动态服务首先需要解决的是得到用户提供的参数再根据参数信息返回。为了和客户端进行交互，服务器需要先创建子进程，之后子进程执行相应的程序去为客户服务。CGI正是帮助我们解决参数获取、输出结果的。

  动态内容获取其实请求报文的头部和请求静态数据时完全相同，但请求的资源从静态的HTML文件变成了后台程序。服务器收到请求后fork()一个子进程，子进程执行请求的程序，这样的程序称为CGI程序（Python、Perl、C++等均可）。通常在服务器中我们会预留一个单独的目录（cgi-bin）用来存放所有的CGI程序，请求报文头部中请求资源的前缀都是/cgi-bin，之后加上所请求调用的CGI程序即可。

  所以上述流程就是：客户端请求程序 -> 服务器fork()子进程 -> 执行被请求程序。接下来需要解决的问题就是如何获取客户端发送过来的参数和输出信息怎么传递回客户端。

• 环境变量

  对CGI程序来说，CGI环境变量在创建时被初始化，结束时被销毁。当CGI程序被HTTP服务器调用时，因为是被服务器fork()出来的子进程，所以其继承了其父进程的环境变量，这些环境变量包含了很多基本信息，请求头中和响应头中列出的内容（比如用户Cookie、客户机主机名、客户机IP地址、浏览器信息等），CGI程序所需要的参数也在其中。

  • GET方法下参数获取

    服务器把接收到的参数数据编码到环境变量QUERY_STRING中，在请求时只需要直接把参数写到URL最后即可，比如"http:127.0.0.1:80/cgi-bin/test?a=1&b=2&c=3"，表示请求cgi-bin目录下test程序，'?'之后部分为参数，多个参数用'&'分割开。服务器接收到请求后环境变量QUERY_STRING的值即为a=1&b=2&c=3。

    在CGI程序中获取环境变量值的方法是：getenv()，比如我们需要得到上述QUERY_STRING的值，只需要下面这行语句就可以了。

      char *value = getenv("QUERY_STRING");
    

    之后对获得的字符串处理一下提取出每个参数信息即可。

  • POST方法下参数获取

    POST方法下，CGI可以直接从服务器标准输入获取数据，不过要先从CONTENT_LENGTH这个环境变量中得到POST参数长度，再获取对应长度内容。

会话机制

HTTP作为无状态协议，必然需要在某种方式保持连接状态。这里简要介绍一下Cookie和Session。

- Cookie

    Cookie是客户端保持状态的方法。

    Cookie简单的理解就是存储由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器可以在响应客户端请求时将Cookie字符串放在Set-Cookie下，客户机收到Cookie之后保存这段字符串，之后再请求时候带上Cookie就可以被识别。

    除了上面提到的这些，Cookie在客户端的保存形式可以有两种，一种是会话Cookie一种是持久Cookie，会话Cookie就是将服务器返回的Cookie字符串保持在内存中，关闭浏览器之后自动销毁，持久Cookie则是存储在客户端磁盘上，其有效时间在服务器响应头中被指定，在有效期内，客户端再次请求服务器时都可以直接从本地取出。需要说明的是，存储在磁盘中的Cookie是可以被多个浏览器代理所共享的。

- Session

    Session是服务器保持状态的方法。

    首先需要明确的是，Session保存在服务器上，可以保存在数据库、文件或内存中，每个用户有独立的Session用户在客户端上记录用户的操作。我们可以理解为每个用户有一个独一无二的Session ID作为Session文件的Hash键，通过这个值可以锁定具体的Session结构的数据，这个Session结构中存储了用户操作行为。

当服务器需要识别客户端时就需要结合Cookie了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用Cookie来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在Cookie里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。如果客户端的浏览器禁用了Cookie，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如sid=xxxxx这样的参数，服务端据此来识别用户，这样就可以帮用户完成诸如用户名等信息自动填入的操作了。