这是我在Coursera上的学习笔记。课程名称为《Computer Networks》，出自University of Washington。

因为计算机网络才诞生不久，眼下正在以快速在发展，所以有些旧的教材可能都已经跟不上时代了。这门课程在2013年左右录制，知识相对还是比較新的。覆盖了计算机网络中的各个协议层，从物理层到应用层都讲得很细致。

学完这门课程之后对计算机网络会有比較深刻的了解。

• 传输层概述

  • 课程位置

    • 我们已经到达传输层了

    • 传输层基于网络层

  • 回顾

    • 传输层是端到端的通信，中间的路由过程不会改变传输层的数据

    • 应用数据包括在TCP包中，TCP包包括在IP包中。IP包包括在帧中

  • 传输层提供的服务

    • 提供框中不同的传输数据方式：UDP TCP

  • UDP和TCP的比較

    • TCP拥有所有特性，UDP仅仅是名义上的传输层。

    • TCP全部的字节仅仅传输一次，按顺序。UDP消息可能会乱序，反复。丢失

    • TCP支持随意长度的内容。UDP仅仅能支持有限长度的内容

    • TCP发送者和接受者能同步流的控制。

      UDP无视网络状态，能够随意发送

    • TCP能够控制堵塞。UDP无视网络状态，能够随意发送

  • SOCKET API

    • 简单的网络抽象接口

    • 支持UDP和TCP

    • SOCKET同意不同的应用使用不同的port

    • UDP和TCP的接口是一样的。除了LISTEN ACCEPT CONNECT是TCP特有的接口，其它接口都是一样的。

  • port

    • 应用程序之间通过IP地址、协议、port来区分不同的应用

    • server通常将port绑定到公认的port上（port号<1024）

    • client通常使用暂时port

  • 公认port

    • 20 21 FTP

    • 22 SSH

    • 25 SMTP

    • 80 HTTP

    • 110 POP3

    • 143 IMAP

    • 443 HTTPS

    • 543 RTSP 多媒体控制

    • 631 IPP 打印机共享

  • 话题

    • UDP TCP 连接 滑动窗体 流控制 重发计时器

      
      

• UDP

  • 话题

    • 用UDP发送消息

  • UDP

    • 在不须要可靠连接的情况下使用UDP

    • 比方VoIP DNS RPC DHCP

  • 数据报SOCKET

    • client。服务端都调用SOCKET

    • 服务端调用BIND

    • 服务端调用RECV FROM（堵塞）

    • client调用SENDTO

    • client调用RECVFROM（堵塞）

    • 服务端调用SENDTO

      
      

    • client和服务端都调用CLOSE

  • UDP缓冲

    • 操作系统接收到数据包时会将数据包保存到内存中，当应用调用RECVFROM时，操作系统会将内存中的数据包传递给应用。这样。应用处理一个数据包时，即使收到数据报也不会丢包

  • UDP包头

    • 使用port来区分不同的应用

    • UDP最长长度为64K

    • 有16位CHECKSUM

    • 详细格式：Source Port | Dest Port | UDP Length | UDP Checksum

    • checksum是可选的，假设是0表示没有校验。（IPv6不可选）

    • checksum覆盖IP地址字段

      
      

UDP check sum计算过程

IPv4 Pseudo Header[edit]

When UDP runs over IPv4, the checksum is computed using a "pseudo header"^[9] that contains some of the same information from the real IPv4 header. The pseudo header is not the real IPv4 header used to send an IP packet, it is used only for the checksum calculation.

The source and destination addresses are those in the IPv4 header. The protocol is that for UDP (see List of IP protocol numbers): 17 (0x11). The UDP length field is the length of the UDP header and data.

UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.

当UDP执行于IPv4时，checksum通过虚拟报头进行计算。虚拟报头中包含了IPv4中的一些字段。虚拟报头不会在数据的传输过程中出现，它仅仅是用来计算checksum。

Source Addr和Dest Addr来自IPv4。UDP protocol为UDP协议号17。UDP length是原来UDP报头中的字段。

UDP checksum在IPv4中是可选的。

假设checksum没实用到，那么它应该设为0。

• 建立连接

  • 话题

    • 怎样建立连接

  • 建立链接

    • 在通信前。发送方和接收方都须要向对方建立连接。

  • 三次握手

    • client生成随机的ISN初始序列号，并向服务端发送SYN（x）

    • 服务端回应客户的请求。生成一个随机的ISN。并向client发送SYN（y）ACK（x+1）

    • client回应ACK（y+1）

    • SYN假设中途丢失，会又一次发送

    • 序列号和ACK号会在兴许的数据包中用到

    • 即使SYN或ACK延迟、反复，TCP也能提供可靠的连接

  • TCP连接有限状态机

    • 见图

    • 状态：CLOSED  LISTEN SYN_SENT SYN_RECV ESTABLISHED

    • 有限状态机是一种帮助考虑全部情况的有利工具

    • TCP同意一次有多个连接

• 释放连接

  • 话题

    • 怎样释放连接

  • 释放连接

    • 有序地释放连接

    • 关键问题是怎样提供可靠的释放机制

      • TCP通过对称的释放机制。服务端和client独立释放连接

  • 步骤

    • 主动方发送FIN（X），被动方发送ACK

    • 被动方发送FIN（Y）。主动方发送ACK

    • FIN假设中途丢失，会又一次传输

    • 每对FIN ACK仅仅关闭一个方向的连接

  • TCP释放有限状态机

    • ESTABLISHED

    • FIN_WAIT_1：等待ACK

    • FIN_WAIT_2：等待对方的FIN

    • TIME_WAIT：为了提高可靠性。关闭连接之后要等待一段时间

    • CLOSED

    • CLOSE_WAIT    

    • LAST_ACK

      
      

  • TIME_WAIT

    • 关闭连接之后等待非常长一段时间。一般是分段生命周期的两倍，也就是2分钟。

    • 由于ACK可能会丢失，这样做是为了让关闭连接更可靠

    • 假设不等待，可能兴许的连接会影响到本次连接

TCP连接有限状态机

TCP释放有限状态机

• 滑动窗体

  • 话题

    • 滑动窗体算法

    • 提高可靠性

    • 基于STOP-AND-WAIT

  • 回顾

    • ARQ协议要求每次发送都须要对方回复ACK，在等待对方回复的时间里，发送方没有传输数据，这样就造成了带宽的浪费

  • STOP-AND-WAIT的限制

    • 一次仅仅能发送一包消息，会造成带宽的浪费

  • 滑动窗体

    • 是STOP-AND-WAIT算法的升级版

    • 同意一次发送W个数据包

    • W=2*带宽*延迟/数据包大小

  • 滑动窗体协议

    • 分为两种：GO-BACK-N、SELECTIVE-REPEAT

    • TCP使用SELECTIVE-REPEAT
      

  • 发送方

    • 当未确认的包小于W时，发送方能够不停地发送数据，直到未确认的包大于W

  • GO-BACK-N

    • 接收方仅仅记录最后ACK的帧号LAS。

    • 当另外一个ACK到达时，假设ACK号为LAS+1。那么将LAS添加1，否则就丢包

  • SELECTIVE-REPEAT

    • 在内存中建立W个缓冲，记录每一个包的状态

    • 当ACK到达后更新包的状态
      

  • 重发

    • GO-BACK-N使用一个计时器来检測数据包的丢失

    • SELECTIVE-REPEAT使用W个计时器来检測丢包

  • 序号

    • 序号的范围是多少比較合适呢

序号随时间变化的图

• 流控制

  • 话题

    • 在滑动窗体算法中添加流控制

    • 防止发送者发送太快

  • 问题

    • 滑动窗体能够充分利用带宽，可是假设接收方无法处理太大量的数据，怎么办呢

  • 接收方

    • 发送方已经接收到数据了。可是没有调用RECV接口。这样的情况下数据包的ACK不会发送，服务端也不会发送很多其它数据

    • 接收方能够直接告诉发送方它能接受的缓冲区大小。WIN=#ACCEPTABLE

  • 流控制

    • TCP中有WIN字段，就是用来流控制的

    • 样例

      • 发送方发送2K数据，SEQ=0

      • 接收方ACK=2048，WIN=2048

      • 发送方发送2K数据，SEQ=2048

      • 接收方ACK=4096。WIN=0

      • 发送方不发送数据，由于WIN是0。表示对方无法接收数据

      • 接收方ACK=4096。WIN=2048

      • 发送方发送1K数据，SEQ=4096

• 超时重发

  • 话题

    • 怎样设置超时重发

  • 重发

    • 在滑动窗体算法中。检測丢包就是通过超时来实现的

  • 超时问题

    • 多久才算超时呢？

    • 在LAN中非常好确定超时时间。由于能够通过RTT（RoundTripTime）来推导，可是在Internet中非常难确定超时时间，由于互联网延迟每一个地方都不一样，RTT都是有差别的。主要原因在于数据包排队

    • 因为网络延迟会变化，所以须要将超时时间自己主动适应不同的网络环境

  • 自适应的超时时间

    • SRTT(n+1) = 0.9*SRTT(n) + 0.1*RTT(n+1)

    • Svar(n+1) = 0.9*Svar(n) + 0.1*|RTT(n+1)-SRTT(n+1)|

    • TCP超时时间(n)=SRTT(n)+4*Svar(n)

    • SRTT = 平滑RTT

    • 这样的方法计算简单。对于性能和健壮性来说这样的方法非常重要

• TCP

  • 话题

    • TCP怎样工作

  • TCP特性

    • 可靠的字节流

    • 基于连接

    • 使用滑动窗体提高可靠性

    • 流控制

    • 通过堵塞控制来分配网络带宽

  • 可靠的字节流

    • client调用四次send函数。接收方可能调用一次recv就把全部的消息都接收完成。由于TCP是字节流，分界点不依靠send

    • 数据双向传递

  • TCP头部格式

    • 见表格

  • TCP滑动窗体 - 接收方

    • 通过递增的ACK告诉发送方。下一个数据包的序号是什么

    • SELECTIVE ACK让发送方得知接收状态

  • TCP滑动窗体 - 发送方

    • 使用自适应的超时重发来又一次发送数据

    • 依据ACK的状况推測丢包情况。马上重发数据。这样做能够避免超时重发的发生

  • TCP头部

    • SYN/FIN/RST 标志是用于连接的

    • WINDOW SIZE 是用于流量控制的

  • 其它TCP细节

    • TCP会有许很多多奇怪的问题，可是这些都属于细节了

    • 最大的问题就是堵塞控制了，下一章将会讲到