TCP/IP 协议详解 第1章 概述

引言

TCP/IP起源于60年代美国政府资助的一个分组交换网络研究项目。

下面的说明来自 维基百科:

  • 分组交换:在计算机网络和通讯中是一种相对于电路交换的通信范例,分组(又称消息、或消息碎片)在节点间单独路由,不需要在传输前先建立通信路径。
  • 电路交换:要求必须首先在通信双方之间建立连接通道。在连接建立成功之后,双方的通信活动才能开始。通信双方需要传递的信息都是通过已经建立好的连接来进行传递的,而且这个连接也将一直被维持到双方的通信结束。在某次通信活动的整个过程中,这个连接将始终占用着连接建立开始时,通信系统分配给它的资源(通道、带宽、时隙、码字等等),这也体现了电路交换区别于分组交换的本质特征。

分层

网络协议通常分为不同层次进行开发,每一层分别负责不同的通信功能。一个协议族,比如TCP/IP,是一组不同层次上的多个系统的组合。

继续阅读

JUC 可重入 读写锁 ReentrantReadWriteLock

读写锁 ReadWriteLock

读写锁维护了一对相关的锁,一个用于只读操作,一个用于写入操作。只要没有writer,读取锁可以由多个reader线程同时保持。写入锁是独占的。

互斥锁一次只允许一个线程访问共享数据,哪怕进行的是只读操作;读写锁允许对共享数据进行更高级别的并发访问:对于写操作,一次只有一个线程(write线程)可以修改共享数据,对于读操作,允许任意数量的线程同时进行读取。

与互斥锁相比,使用读写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率,以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。

读写锁适用于读多写少的情况。

可重入读写锁 ReentrantReadWriteLock

属性

ReentrantReadWriteLock 也是基于 AbstractQueuedSynchronizer 实现的,它具有下面这些属性(来自Java doc文档):

  • 获取顺序:此类不会将读取者优先或写入者优先强加给锁访问的排序。
    • 非公平模式(默认):连续竞争的非公平锁可能无限期地推迟一个或多个reader或writer线程,但吞吐量通常要高于公平锁。
    • 公平模式:线程利用一个近似到达顺序的策略来争夺进入。当释放当前保持的锁时,可以为等待时间最长的单个writer线程分配写入锁,如果有一组等待时间大于所有正在等待的writer线程的reader,将为该组分配读者锁。
    • 试图获得公平写入锁的非重入的线程将会阻塞,除非读取锁和写入锁都自由(这意味着没有等待线程)。
  • 重入:此锁允许reader和writer按照 ReentrantLock 的样式重新获取读取锁或写入锁。在写入线程保持的所有写入锁都已经释放后,才允许重入reader使用读取锁。
    writer可以获取读取锁,但reader不能获取写入锁。
  • 锁降级:重入还允许从写入锁降级为读取锁,实现方式是:先获取写入锁,然后获取读取锁,最后释放写入锁。但是,从读取锁升级到写入锁是不可能的。

  • 锁获取的中断:读取锁和写入锁都支持锁获取期间的中断。

  • Condition 支持:写入锁提供了一个 Condition 实现,对于写入锁来说,该实现的行为与 ReentrantLock.newCondition() 提供的 Condition 实现对 ReentrantLock 所做的行为相同。当然,此 Condition 只能用于写入锁。
    读取锁不支持 ConditionreadLock().newCondition() 会抛出 UnsupportedOperationException

  • 监测:此类支持一些确定是读取锁还是写入锁的方法。这些方法设计用于监视系统状态,而不是同步控制。

继续阅读

TCP/IP 协议详解 第22、23章 TCP的定时器

第22章 TCP的坚持定时器

TCP通过让接收方指明希望从发送方接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为0将有效阻止发送方传送数据,直到窗口变为非0为止。

ACK的传输不可靠,TCP不对ACK报文段进行确认,TCP只确认那些包含有数据的ACK报文段。

为了防止 “接收方等待接收数据(因为它已经向发送方通告了一个非0窗口),而发送方在等待允许它继续发送数据的窗口更新” 这种死锁发生,发送方使用一个坚持定时器(persist timer)来周期性地向接收方查询,以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查(window probe)。

坚持状态与重传超时之间的一个不同的特点就是TCP从不放弃发送窗口探查,这个过程将持续到 或者窗口被打开,或者应用程序使用的连接被终止。

糊涂窗口综合症

糊涂窗口综合症(SWS,Silly Window Syndrome)发生时会出现:少量的数据将通过连接进行交换,而不是满长度的报文段。

该现象可发生在两端中的任何一端:接收方可以通告一个小的窗口(而不是一直等到有大的窗口时才通告),而发送方也可以发送少量的数据(而不是等待其他的数据以便发送一个大的报文段)。可以在任何一端采取措施避免出现糊涂窗口综合症的现象。

  • 接收方不通告小窗口。通常的算法是接收方不通告一个比当前窗口大的窗口(可以为0),除非窗口可以增加一个报文段大小(也就是将要接收的MSS)或者可以增加接收方缓存空间的一半,不论实际有多少。

第23章 TCP的保活定时器

保活定时器不是TCP规范的一部分。

保活功能主要是为服务器应用程序提供,试图在服务器端检测客户端已消失的半开放的连接。

使用保活选项的一端称为服务器,另一端则为客户端,可以两端都使用。

如果一个给定连接在两个小时内没有任何动作,则服务器向客户发送一个探查报文段。客户主机必须处于以下4个状态之一:

  1. 客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此连接,则定时器在交换数据后的未来2小时再复位。
  2. 客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务器将不能够收到对探查的响应,并在75秒后超时。服务器总共发送10个这样的探查,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。
  3. 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应,但是这个响应是一个复位,使得服务器终止这个连接。
  4. 客户主机正常运行,但是从服务器不可达。这与状态2相同,因为TCP不能够区分状态4与状态2之间的区别,它所能发现的就是没有收到探查的响应。

欢迎关注我的微信公众号: coderbee笔记,可以更及时回复你的讨论。

TCP/IP 协议详解 第21章 TCP的超时与重传

TCP通过确认从另一端收到数据来提供可靠的运输层,由于数据和确认都有可能丢失,TCP通过在发送时设置一个定时器来解决这种问题,当定时器溢出时还没有收到确认,它就重传该数据。对于任何实现而言,关键在于超时和重传的策略。

对于每个连接,TCP管理4个不同的定时器:

  • 重传定时器 使用于当希望收到另一端的确认。
  • 坚持(persist)定时器 使窗口大小信息保持不断流动,即使另一端关闭了其接收窗口。
  • 保活(keepalive)定时器 可检测到一个空闲连接的另一端何时崩溃或重启。
  • 2MSL定时器 测量一个连接处于 TIME_WAIT 状态的时间。

在进行超时重传时,两次重传的时间间隔是一个倍乘关系(每次增加1倍),称为“指数退避(exponential backoff)”。

继续阅读