人类简史图片版(精华呀！！)

介绍2个Podcast网站(有免费资源的)

最近买了IPod Video,随后就玩起了Podcast，满处去找播客，最近发现2个比较好的并且大大的免费的播客网站，特共享之~~~
操作非常简单，我就不说了，可以配合自己的iTune一起使用，或者直接down下来，随便了~~希望大家喜欢，有好的别忘了交换一下。

国内：http://www.antiwave.net/
国外：http://podiobooks.com/

两个日本很著名的AV女优Blog！！！

(あいか瞬)あいか瞬公式ブログ http://blog.dmm.co.jp/actress/aika_shun/
(愛川みき)ホルモンおっぱいニューハーフ http://blog.livedoor.jp/aikawamiki/

PS：到底有什么特别的呢？我不懂日文呀~~~

TCP协议理解之一

TCP协议到处都在使用。理解TCP协议的工作原理能够帮助管理员正确诊断网络通信的故障。
　　TCP协议很复杂。不过不用担心。我们不是让你去阅读RFC 793。本文只是一篇启蒙讲座。在本次讲座中，我们将仅仅介绍为了让你理解下一篇关于TCP协议的讲座所需的知识。经过本文的学习你会了解一些TCP相关的术语，理解TCP包头的各组成部分，然后，我们将在后面一篇文章中重点讲解TCP协议常见的一些问题，包括TCP窗口可伸缩性问题、阻塞和TCP连接机制等问题。
　　我们有时候听到人们提到“TCP/IP协议栈”。这意味着他们在谈论1至4层和7层的问题，TCP协议位于第四层。其代表的含义是传输控制协议(Transmission Control Protocol)。还记得IP协议那篇文章中的协议头的构成吗?当一个数据包被封装之后，第三层当然有个IP协议头，紧接着就是这个TCP协议头。TCP协议头成为了IP协议头中的“数据”。就像其它协议都有自己的术语一样，TCP协议也有自己的专门术语，如以太网帧、IP数据报和现在的TCP段等。你可以把它们都当作数据包。但是，当它们之间在进行通讯的时候，一定要使用正确的术语。
　　TCP协议是一种端对端的协议。使用TCP没有任何广播或类似的概念。要用TCP协议与另一台计算机通信，两台机之间必须像打电话一样连接在一起，每一端都都为通话做好准备。“流传输”(Stream delivery)是谈到TCP时的另一个常用词语。这个短语的含义是TCP协议主要用来处理数据流，可以正确处理乱序的数据包。TCP协议甚至还允许存在丢失的或者损坏的数据包，最终它可以再次得到这些数据包。你很可能听一位程序员在谈论“流”的概念。他指的是这样一个事实:数据到底是在什么时候发送的是很难说清楚的，你也可以在TCP流中发送非结构化数据。TCP协议以它自己的方式缓存数据。不过，其缓存过程对程序员和用户是透明的。
　　TCP协议每发送一个数据包将会收到一个确认信息。这种发送/应答模式是提供可靠的协议的唯一方法:你必须让对方知道你否收到了数据。当然，这也会造成一些性能损失，而人们需要改善系统效率不高的状况。所以引入了“捎带确认（piggybacking ACKs）”的方法。TCP协议之所以是全双工的就是因为这个“捎带确认”信息，因为它允许双方同时发送数据。这是通过在当前的数据包中携带以前收到的数据的确认信息方式实现的。从提高网络利用率的角度看，这比单纯发送一个通知对方“信息已收到”的数据包要好得多。最后，还有一个批量确认的概念：也即一次确认一个以上的数据包，表示“我收到了包括这个数据包在内的全部数据包”。
　　在IP协议中，我们处理的单个数据包是一个更大的数据报的一部分。请记住，一个TCP段就是一个单个的TCP数据包。TCP是一个数据流，因此，除了“连接”之外，没有任何需要真正担心的其它概念。最大报文段长度(MSS)是在连接的时候协商的，但是，它总是在不断地改变。默认的最大报文段长度是536字节，这是576字节(IP协议保证的最小数据包长度)减去用于IP头的20个字节和用于TCP头的20个字节以后的长度。TCP协议要设法避免在IP级别上的分段。因此，TCP协议总是从536字节开始的。
　　TCP协议最有魅力的功能仍然保留着。这就是滑动窗口协议。这个窗口实际上是已经发出的“没有签收确认的”数据总数。这个窗口可以根据意愿放大和缩小。这是很有趣的。下一讲将介绍这方面的内容。
　　一个TCP数据包的头是20个字节，就像一个IP数据包一样。如果使用一些选项，IP和TCP数据包头都可以放大。TCP头不包含IP地址，它仅需要知道要连接哪一个端口。不过，你不要被这弄晕了。TCP工作时要一直跟踪状态表中的端对端的连接。这个状态表包含IP地址和端口。这就是说，只是TCP头不需要IP信息，因为它来自于IP头。
　　把一个数据包设想为一个字节跟着一个字节的数据流是很容易的。很多人都想要一个显示TCP头的表格。但是，这常会把事情搞乱。TCP头从第一位开始依次是下面这些内容:
　　•源端口，16位:用于这次连接的本地TCP端口。
　　•目的地端口，16位:通讯目标机器的TCP端口。
　　•序列号，32位:用来跟踪数据包顺序的号码。
　　•确认编号，32位:我们确认的以前收到的序列号。
　　•头长度，4位:报头中的32位字(words)的数量。如果不使用选项，这个值设定为5。
　　•保留，6位:为将来的使用保留的字节。
　　•标记，一共6位:每一个标记一个字节(开或者关)
　　-URG:紧急字段指针。
　　-ACK:本数据包是(或者包含)一个确认信息。
　　-PSH:推送功能(没有使用)。
　　-RST:重置，或者中断本次连接。
　　-SYN:同步数据包，也就是开始连接。
　　-FIN:最后一个数据包，开始挂断序列。
　　•窗口尺寸，16位:从接收方将收到的确认字段开始。
　　•校验和，16位:TCP头和数据的校验和。
　　•应急指针，16位:指向跟在URG数据后面的数据的序列号的偏移值。
　　•选项:MSS、窗口比例等等。我们在关于TCP协议的下一讲中将重点介绍这个部分。
　　TCP连接的两端使用两对IP地址和端口识别这个连接，并且向监听这个端口的应用程序发送数据。

小结
　　TCP是一种最常用的协议，在协议栈中位于第四层。
　　TCP协议提供阻塞控制、可靠性和发送数据的流。
　　为了提高效率，TCP协议在得到确认之前努力发送尽可能多的数据。

TCP协议理解之二

原来看到的一篇文章，个人感觉比较好，转一下。

首先，TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN数据包。这只是一个不包含数据的数据包，然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，会向发送方发送一个最终的确认信息（ACK包）。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到超时或者任何一方发出一个FIN(结束)信号。
　　任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接已经关闭了，并且关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。
　　现在，我们来讨论一个问题。如果有人(假如一个黑客)在你的Web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCP SYN 攻击的话，那就是这个意思。为了防止出现这种情况，大多数操作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。
　　下面我们将讨论关于持续流控制问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信息，它实际上就把数据吞吐量削减了一半。
理想的情况是，我们能够一次发送许多数据包，然后等待收到一个确认收到全部数据包的ACK信息，而不用对方发来更多的数据。但是，我们如何知道发送了多少个数据包呢?TCP窗口尺寸可以控制在“已发送但是没有确认”的状态下能够容纳多少个数据包。如果这个窗口尺寸很大，我们不必等待ACK信息就可以发送大量的数据包。这实际上就是流控制。
　　接收方就是控制窗口大小的那一方。如果接收方将窗口大小设为“0”，那么，发送方根本就不能发送任何数据。如果这个窗口的尺寸是“1”，那么，我们就回到了简单的“发送和等待ACK”的协议。如果最后的窗口尺寸是“0”，发送者将发出一个探测信号以搞清这个窗口什么时间再次打开。如果发送方从来没有收到ACK信息，它就一直不断地重试，直到定时器过期。请记住，这个窗口尺寸在TCP头中是一个16位字段。如果你要一个窗口尺寸(按字节计算)大于16位可以表示的容量（2的16次方个字节），还可以使用一个名为“窗口缩放”的TCP协议选项。这个选项允许窗口尺寸乘以比例因子。如果没有极大的窗口尺寸，TCP协议就就无法充分利用GB级别的高速连接。这也是我们需要针对这些新的高速连接调整TCP参数的原因，
　　关于TCP流控制的问题，我们不能不提一下Nagle算法。如果我们在一个telnet连接上使用一个大的TCP窗口会发生什么事情呢?你会输入一个指令（例如敲了一个字母），然后一直等待回应它却迟迟不出现在终端回显上。这对于实时通信来说是一个大问题。而且，telnet也会增加网络的阻塞度，因为一个字节的数据（例如我们的一次击键）需要40个字节的包头。于是RFC 896定义这个Nagle算法，用以消除小的数据包。这个思路是我们应该在数据发送之前给先把小数据集中起来然后一次性发送，以便提高效率。为了更有效率，它还限定只允许存在一个未经确认的数据段，你在得到确认信息之前不能发送更多的数据。Telnet和互动SSH连接使用TCP_NODELAY套接口选项启用这个功能，这样当你按下一个按键的时候，你能够立即得到一个回应。
　　当然，我们仍是忽略了有关TCP协议的许多事情。然而，通过这两篇文章的了解，你应该能够理解其它一些更专业的TCP著作。阻塞控制与流控制不同，本文没有讨论。如果你真的对了解TCP协议的全部工作原理感兴趣，你可以详细阅读TCP RFC。
　　小结
　　TCP协议非常善于解决流控制问题，因此非常适应于许多应用程序。TCP协议中的流控制的含义是:“在收到对发送的数据的确认信息这前，我可以发送多少数据?”这就是TCP窗口。需要指出的是，在TCP协议之下连接速度开始很慢，然后速度逐渐加快。这个做法并不总是最理想的。