计算机网络体系结构
TCP/IP协议族
TCP / IP 网络传输中的数据术语
网络通信中的地址和端口
window端查看IP地址 和MAC地址 ：ipconfig -all
MAC层地址是在数据链路层的；IP工作在网络层的
MAC是48个字节，IP是32个字节
在子网（局域网）中通过MAC来寻址，上网时需要IP来寻址。
eg:在一个局域网环境（或wifi环境）中，当新加一台机器A到这个局域网来时，那么机器A需要想DMCH服务器申请一个IP地址，然后机器A拿到后，通过ARP协议将自己的MAC地址和IP地址向该局域网的其他机器进行公告。
通信网路中的地址和端口号
端口工作在TCP层
为什么会有65535个端口？
在TCP协议和UDP协议中有报文头里面有专门的字段（2个字节）来存放端口号，即2的16次方减一 等于65535个。（端口0表示所有的端口）
问题：
因为端口只有65535个，所以一台主机只能保持最多65535个TCP连接，对么？
不对，对于服务端，服务端ip及端口不变，则源ip和源端口变化，源ip占4个字节(1个字节8个bit位)即2的32次方，源端口2个字节即2的16次方。两个相乘大致有200万亿个理论值。
**对于客户端，客户端不变，目标ip,目标端口变，而且客户端可以访问不同服务器的，当没有显示使用端口时，客户端的操作系统会默认复用端口去使用的。**则在200万亿的基础上再乘以2的16次方。
TCP特性
三次握手，四次握手
TCP3次握手的漏洞之SYN洪泛攻击
TCP的四次挥手（分手）
为什么需要Time-wait状态？
问题：当服务器出现time-wait，请问大概是什么原因造成的？
程序代码中没有主动取close连接，导致服务器端经过长时间判定这个用户很长时间没有发送报文过来了（这个用户是否已下线），则服务端主动发起了close连接。
(3)一段时间后，被动关闭的应用进程将调用 close 关闭它的套接字。这导致它的 TCP 也发送一个 FIN，表示它也没数据需要发送了。
(4)接收这个最终 FIN 的原发送端 TCP (即执行主动关闭的那一端)确认这个 FIN 发出-个确认 ACK 报文，并进入了 TIME-WAIT (时间等待)状态。**注意此时 TP 连接还没有释放必须经过 2*MSL(最长报文段寿命/最长分节生命期 max segement lifetime，MSL 是任何IP数据报能够在因特网中存活的最长时间，任何 TCP 实现都必须为 MSL 选择一个值。RFC1122[Braden 1989]的建议值是 2 分钟，不过源自 Berkelcy 的实现传统改用 30 秒这个值。**这意味着 TIME WAIT 状态的持续时间在 1分钟到 4 分钟之间)的时间后，当主动关闭端撤销相应的 TCB 后，才进入 CLOSED 状态。
(5) 被动关闭端只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB后，就结束了这次的 TCP 连接。可以看到，被动关闭端结束 TCP 连接的时间要比主动关闭端早一些。
既然每个方向都需要一个 FIN 和一个 ACK，因此通常需要 4 个分节。我们使用限定词"通常"是因为:某些情形下步骤 1的 FIN 随数据一起发送;另外，步骤 2 和步3 发送的分节都出自执行被动关闭那-一端，有可能被合并成一个分节。
UDP协议
UDT
基于 UDP 的数据传输协议 (UDP-based Data Transfer Protocol，简称 UDT)是一种互联网数据传输协议。UDT 的主要目的是支持高速广域网上的海量数据传输，最典型的例子就是建立在光纤广域网上的网格计算，一些研究所在这样的网络上运行他们的分布式的数据密集程式，例如，远程访问仪器、分布式数据挖掘和高分辨率的多媒体流。
而互联网上的标准数据传输协议 TCP 在高带宽长距离网络上性能很差。 顾名思义，UDT 建于 UDP 之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。UDT 的特性主要包括在以下几个方面:
**基于 UDP 的应用层协议:**有基本网络知识的朋友都知道 TCP 和 UDP 的区别和使用场景，但是有没有一种协议能同时兼顾 TCP 协议的安全可靠和 UDP 协议的高效，那么 UDT 就是一种。
面向连接的协议:面向连接意味着两个使用协议的应用在彼此交换数据之前必须先建立一个连接，当然 UDT 是逻辑上存在的连接通道。这种连接的维护是基于握手、Keep-alive (保活) 以及关闭连接。
可靠的协议: 依靠包序号机制、接收者的 ACK 响应和丢包报告、ACK 序号机制、重传机制(基于丢包报告和超时处理)来实现数据传输的可靠性。
双工的协议: 每个 UDT 实例包含发送端和接收端的信息。
新的拥塞算法，并且具有可扩展的拥塞控制框架: 新的拥塞控制算法不同于基于窗口的 TCP 拥塞控制算法(慢启动和拥塞避免)，是混合的基于窗口的、基于速率的拥塞控制算法。可扩展的拥塞控制框架开源的代码和拥塞控制的 C++类架构，可支持开发者派生专用的拥塞控制算法。
带宽估计: UDT 使用对包(PP - Packet pair)的机制来估计带宽值。即每 16 个包为一组,最后一个是对包,即发送方不用等到下一个发送周期内再发送。接收方接收到对包后对其到达时间进行记录,可结合上次记录的值计算出链路的带宽(计算的方法称为中值过滤法)，并在下次 ACK 中进行反馈。
QUIC
QUIC代表"快速 UDP Internet 连接"，基于 UDP 的传输层协议，它本身就是 Google 尝试将 TCP 协议重写为一种结合了 HTTP/2、TCP、UDP 和TLS(用于加密)等多种技术的改进技术。
谷歌希望 QUIC 通信技术逐渐取代 TCP 和 UDP，作为在 Internet 上移动二进制数据的新选择协议，QUIC 协议的主要目的，是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率。
由于 TCP 是在操作系统内核和中间件固件中实现的,因此对 TCP 进行重大更改几乎是不可能的(TCP 协议栈通常由操作系统实现，如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程，因为每种设备、系统的实现都需要更新)。但是，由于 QUIC 建立在 UDP 之上，因此没有这种限制。
QUIC 的优势在于:
1、采用多路复用 思想，一个连接可以同时承载多个 流(stream )，同时发起多个请求。 请求间完全 独立 ，某个请求阻塞甚至报文出错均不影响其他请求。
2、QUIC 只需要 1RTT(Round-Trip Time)的延迟就可以建立可靠安全的连接相对于 TCP+TLS 的3 次 RTT 要更加快捷。之后客户端可以在本地缓存加密的认证信息，再次与服务器建立连接时可以实现 O-RTT 的连接建立延迟。
3、TCP 采用 重传 机制，而 QUIC 采用 纠错 机制。