计算机网络学习笔记
19th,April,2016;20th,April,2016;21st,April,2016;25th,April.2016;26th,April,2016;27th,April,2016；28th,April,2016
更新中......
应用层
HTTP协议
超文本传输协议(HyperText Transfer Protocol,HTTP)，无状态高并发。协议中定义了报文的格式，以及客户端与服务器进行报文交换的规则。
该协议基于TCP协议，客户端发起一个与服务器端的TCP连接，客户端与服务器进程通过套
接字接口访问TCP。
多个端系统间的程序进行通信，实际上是 进程间进行通信 ，通过IP地址与端口号唯一标识一个进程（进程寻址）。不同端系统间的进程通过跨越计算机网络交换报文而相互通信。进程通过称为socket的软件接口在网络上发送和接收报文。
Socket套接字
同一台主机内应用层与运输层之间的接口，也可称为应用程序和网络之间的应用程序编程接口(Application Programming Interface,API)。应用层开发者对于运输层的控制仅限于一个是选择运输层协议，另一个是设置几个运输层参数。
每个套接字都有唯一标识符，标志符的格式可分辨是TCP套接字还是UDP套接字。
Socket套接字
同一台主机内应用层与运输层之间的接口，也可称为应用程序和网络之间的应用程序编程接口(Application Programming Interface,API)。应用层开发者对于运输层的控制仅限于一个是选择运输层协议，另一个是设置几个运输层参数。
每个套接字都有唯一标识符，标志符的格式可分辨是TCP套接字还是UDP套接字。
端口号
端口号是一个16比特的数字，大小在0-65535之间。其中0-1023的端口号是周知端口号(well-hnown port number),保留给周知应用层协议(如HTTP,FTP等)，周知端口的列表在RFC 1700中，
http://www.iana.org
网站有相应的更新文档。
以下为一些常见的端口号：
HTTP 80
FTP 21
HTTPS 443
SMTP 25
Telnet 23
SSH 22
DNS 53
长连接 && 短连接
也称持久连接与非持久连接，主要是针对运输层协议为TCP时，通过一个TCP连接传送一个请求还是所有的请求，前者是
短连接，后者是长连接。
短连接过程
1）客户机程序在80端口发起一个到服务器的TCP连接，握手成功后建立TCP连接
2） 客户机程序通过套接字向服务器发送请求报文
3） 服务器通过套接字接收请求报文，并做相应的响应操作，发送响应报文给客户机程序
4） 服务器进程通知TCP断开该TCP连接（服务器待确认客户端完整接收到响应报文后，断开连接）
5） 客户机接收断开报文，关闭TCP连接
运输层
简介
为运行在不同主机上的应用进程提供了逻辑通信功能。接收应用进程的报文转换成运输层分组，即运输层报文段(segment)。
多路分解与多路复用
多路分解(multiplexing): 将运输层报文段中的数据
交互给正确的套接字
如何实现多路分解：主机上的套接字有分配端口号，通过检查报文段中的目的端口号，
定向到相应的套接字。通过套接字进入所连接的进程。
多路复用(demultiplexing): 从不同套接字收集数据块，并为每个数据块封装上首部消息从而生成报文段，然后把报文端传递到网络层的工作。
多路复用的要求：1）套接字有唯一标识符。2）每个报文段有
特殊字段(源端口号字段和目的端口号字段)
来指示该报文段要交互的套接字。
TCP && UDP
运输层协议提供的服务，通过认识运输层协议提供的服务，区分TCP协议与UDP协议。主要分为四个： 可靠数据传输，
吞吐量，定时和安全性。
传输控制协议(Transfer Control Protocol,TCP)，提供可靠的数据传输服务；
面向连接服务； 可通过SSL来提供安全服务；有拥塞控制
用户数据报协议(User Datagram Protocol,UDP)，不提供不必要服务的轻量级运输层协议；不提供可靠数据传输；无连接，通信前没有握手存在数据丢失，是一种不可靠面向报文的服务模型；无拥塞控制
目前TCP与UDP中缺少对吞吐量和定时保证的讨论，即运输层协议未提供这两项服务。
UDP套接字是有一个二元祖（目的IP地址，目的端口号）来标识。两个不同源IP地址和/或源端口号，具有相同目的IP地址和目的端口号，则两个报文段会通过相同的套接字定向到相同的目的进程。
TCP套接字是由一个四元组(源IP地址，源端口号，目的IP地址，目的端口号）来标识。两个不同源IP地址和/或源端口号，具有相同目的IP地址和目的端口号，则这两个报文段将通过不同的套接字。
⚠：连接套接字和进程并非总是有着一对一对应的关系，事实上，一些高性能的Web服务器一般只使用一个进程，但是为不同套接字（具有不同的标识）创建线程。
使用非持久连接，频繁的创建和关闭套接字会严重影响到一个
繁忙的Web服务器的性能。
拥塞控制
防止任何一条TCP连接用过多流量来淹没通信主机之间的链路和交换设备，平等的共享网络链路带宽。
吞吐量
发送进程向接收进程交付比特的速率
面向连接
客户端与服务端数据传输前，需先握手，握手成功后，两个进程的套接字之间建立了一个TCP连接。这个连接是
全双工的。
单工 半双工 全双工
单工(Simplex)： 通信过程中，发送方与接收方是固定的，只能由发送方发送数据给接收方
eg: 典型的单工发送设备有早期计算机的读卡器，典型的单工接收设备如打印机
半双工(Half Duplex):通信过程中可以充当发送方的角色，也可以充当接收方的角色。但不能同时发送与接收数据。
eg: 步话机，HTTP协议基于请求响应机制，只能开启半双工的通信通道。
全双工(Full Duplex): 通信过程中可以同时接收发送数据。
eg: 电话，WebSocket协议可开启全双工的通信通道。
UDP
使用UDP的应用
可以实现可靠数据传输
，需在应用程序中建立可靠性机制（eg：增加确认与重传机制）。
UDP报文段结构
首部有4个字段，每个字段由两个字节组成。分别为 源端口号，目的端口号，长度，
检验和
UDP检验和
提供了差错检验功能，用于确定报文段到达目的地时，其中比特是否发生了变化。
方法：发送方的UDP对报文段中所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。
UDP提供检验和的原因
1.其中许多链路层协议也提供差错检验。但不能保证所有源和目的之间的所有链路都提供差错检验。
2. 当报文段存储在某台路由器的内存中时，也可能引入比特差错。比特差错通常会出现在网络的物理部件中
因而，UDP必须在端到端基础上在运输层提供差错检验。
端到端原则(end-end princeple): 某种功能(如差错检验)必须基于端到端实现，“与在较高级别提供这些功能的代价相比，在较低级别上设置的功能可能是冗余或几乎没有价值的”
⚠：UDP提供差错检验，但不能进行差错恢复。
选择UDP的原因
（实时应用）
1. 应用层能更好的控制要发送的数据和发送时间；
2. 无需建立连接，不会引入建立连接的时延；
3. 无连接状态，无需维护连接状态（包括接收和发送缓存，拥塞控制参数，序号与确认号的参数），也不需跟踪这些参数。
4. 分组首部开销小。TCP报文段20字节的首部开销，UDP8字节的开销。
eg: RIP选路表的更新； DNS; SNMP等都是运行在UDP之上。
可靠数据传输原理
通过可靠信道，数据按照发送顺序进行传送
可靠数据传输协议(reliable data transfer protocol): 下层协议可能是不可靠的
单向数据传输(unidirectional data transfer)
双向数据传输(bidirectional data transfer)：即全双工数据传输
以下仅考虑单项数据传输
构造完全可靠信道上的可靠数据传输：rdt1.0
有限状态机(finite-state machine,FSM)
rdt1.0中FSM只有一个状态，因而变迁必定是从原状态回到自身。
发送方：引起变迁的事件rdt_send(data)，变迁发生采取的动作是packet=make_pkt(data),udt_send(packet)
接收方：引起变迁的事件rdt_rcv(packet)，变迁发生采取的动作是extract(packet,data),deliver_data(data)
有了完全可靠的信道，接收方就不需要提供任何反馈信息给发送方。
具有比特差错信道上的可靠数据传输：rdt2.0
口述消息协议使用
肯定确认(positive acknowledgment)与
否定确认(negative acknowledge)
基于这种
重传机制的可靠数据传输协议称为
自动重传请求(Automatic Repeat reQuest, ARQ)协议
差错检验： 需要一种机制使接收方检测到何时出现了比特差错
接收方反馈：发送方要了解接收方情况（比如分组是否被正确接收）的唯一途径就是让接收方提供明确的反馈信息给发送方。口述消息协议中的肯定确认和否定确认正是基于该反馈机制。
重传：接收方收到有差错的分组时，发送方将重传该分组。
rdt2.0的FSM
发送方：等待来自上层的数据->触发rdt_send(data)->sndpkt=make_pkt(data, checksum)产生待发送数据的分组并计算出分组检验和->udt_send(sndpkt)->wait-for-ACK-or-NAK(等待接收方的反馈分组)->收到ACK,进入等待上层数据状态/收到NAK,重传最后一个分组，进入wait状态。
⚠：发送方在等待信息时，不能获取来自上层的数据。知道接收到ACK并离开改等待状态才能获取数据，也可称为停等(stop-and-wait)协议。
接收方：只有一个状态，分组到达时，回答ACK/NAK,
rdt2.0协议看起来似乎可行，但有一个致命的缺陷：
没有考虑到ACK或NAK分组受损的可能性。
解决该问题的方法： 在数据分组中添加新字段,发送方对数据进行分组编号，将发送数据的分组的序号(sequence number)放在该字段。
参考资料：
《计算机网络自顶向下方法》
Socket长连接与短连接