转：http://blog.csdn.net/sundacheng1989/article/details/28239711
http://blog.csdn.net/sundacheng1989/article/details/52437128
在C#编写代码，很多时候会遇到Http协议或者TCP协议，这里做一个简单的理解。
TCP协议对应于传输层，而HTTP协议对应于应用层，从本质上来说，二者没有可比性。Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，是一种无状态的连接。所谓的无状态，是指浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。如果是一个连接的话，服务器进程中就能保持住这个连接并且在内存中记住一些信息状态。而每次请求结束后，连接就关闭，相关的内容就释放了，所以记不住任何状态，成为无状态连接。
随着时间的推移，html页面变得复杂了，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次tcp连接就显得低效了。因此Keep-Alive被提出用来解决效率低的问题。从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。虽然这里使用TCP连接保持了一段时间，但是这个时间是有限范围的，到了时间点依然是会关闭的，所以我们还把其看做是每次连接完成后就会关闭。后来，通过Session, Cookie等相关技术，也能保持一些用户的状态。但是还是每次都使用一个连接，依然是无状态连接。
以前有个概念很容忍搞不清楚。就是为什么Http是无状态的短连接，而TCP是有状态的长连接？Http不是建立在TCP的基础上吗，为什么还能是短连接？现在明白了，Http就是在每次请求完成后就把TCP连接关了，所以是短连接。而我们直接通过Socket编程使用TCP协议的时候，因为我们自己可以通过代码区控制什么时候打开连接什么时候关闭连接，只要我们不通过代码把连接关闭，这个连接就会在客户端和服务端的进程中一直存在，相关状态数据会一直保存着。
在C#中会有Socket，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write等等。
比较形象的描述：HTTP是轿车，提供了封装或者显示数据的具体形式;Socket是发动机，提供了网络通信的能力。对于从C#编程的角度来讲，为了方便，你可以直接选择已经制造好的轿车Http来与服务器交互。但是有时候往往因为环境因素或者其他的一些定制的请求，必须要使用TCP协议，这时就需要使用Socket编程，然后自己去处理获取的数据。就像是你用已有的发动机，自己造了一辆卡车，去从服务器交互。
HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。HTTP客户首先发起建立与服务器TCP连接。一旦建立连接，浏览器进程和服务器进程就可以通过各自的套接字来访问TCP。如前所述，客户端套接字是客户进程和TCP连接之间的“门”，服务器端套接字是服务器进程和同一TCP连接之间的“门”。客户往自己的套接字发送HTTP请求消息，也从自己的套接字接收HTTP响应消息。类似地，服务器从自己的套接字接收HTTP请求消息，也往自己的套接字发送HTTP响应消息。客户或服务器一旦把某个消息送入各自的套接字，这个消息就完全落入TCP的控制之中。TCP给HTTP提供一个可靠的数据传输服务;这意味着由客户发出的每个HTTP请求消息最终将无损地到达服务器，由服务器发出的每个HTTP响应消息最终也将无损地到达客户。
C#代码连接远程数据库用的是TCP协议。每次new 一个connection的时候，connection.open就打开了这个TCP连接。connection.Close的时候就关闭了这个连接。FTP的底层也是TCP， 不过是长连接的。传输大文件比较快。 需要看具体场景。在服务器端，如果程序是采取的长连接的方式，那么就能控制同时连接到这个服务器的连接个数，防止同时有多个连接。但是采取短连接的方式，那么就不能控制同时连接到这个服务器上的连接的个数，这也是一个优点，可以同时处理大量连接请求。但是如果连接请求量太大的话，可能造成服务器停止工作。
WebService不需要连接，一秒中至少可以支持上万/十万的请求，每次请求然后释放，没有空余的内存消耗。一般不会限制同时连接的个数，这是优势。Message Queue需要建立连接， 支持上千的连接就很吃力了。因为每个连接即使没有在请求数据，也会在内存中占用一定的空间存储。会限制，比如SQL Server数据库服务器，一般最多同时连接16个。
Http协议一定通过指定的端口，80，所以一般计算机上不会限制这个端口，所以Http协议能够顺利通过所有机器上的防火墙。而使用Socket编程的话，就需要自己指定特定的端口，那么很可能这个端口是在某个环境中禁用的，那么就无法穿透防火墙。IIS使用的是80端口，也就是这个程序一直在监听着这个端口。一旦发现有人要建立到这个端口的连接，他就会响应，然后建立连接。这里说的连接都是短连接。所以你对服务器上的网址的请求，都是通过80端口送到网站程序的。然后通过这个端口发送的客户端浏览器。
2016-09-05更新：
最近读了读《TCP/IP协议卷》，又写了一篇后续文章，文章链接。
大约2年前写了一篇关于HTTP协议与TCP协议的文章，原文链接。最近再次简单读了一遍《TCP/IP协议卷》，有了一些新的理解。这篇文章没有一个很好的连贯性，都是我在读书过程中总结的知识点，整体比较松散，但是个人感觉知识点都是非常重要，有很多地方让我明白了迷惑很久的问题。
写了这么长时间的代码，发现自己对TCP/IP了解的并不是很透彻。虽然会用C#的HttpClient类来进行网络编程，也可以使用Chrome的开发者工具来检测每一次的HTTP请求的报文头与报文体，也知道cookie的存在方式，但是对于这些数据怎么在网络上传输还是很模糊，数据是怎么从客户端的文件或者字符串转换为二进制数并且传送到服务器端的？为了弄明白这些问题，最近大致的读了读《TCP-IP详解(卷一、二、三)》，也算是比以前清楚多了，下面是读的过程中的一些知识点。
首先，我们要弄明白这个计算机网络分层的概念。下边这个图是一个经典的分层描述，记得大学时候课本上的图也跟这个差不多。
但是我更觉得，大家思想上都有一个抽象的概念，就是分层是垂直的，从上到下的。其实，我觉得，更准确的说，这个分层应该是水平的，从左到右的，就像车间的生产线，进去一个大的需要处理的原料，经过不同的操作台，一层一层的切割，包装，到最后出来的时候就成为了很多精致的小产品。
关于网络层。
网络层有不同的协议，如IP与ICMP，两者的不同就是对于上层传过来的数据根据什么样的格式进行切割，然后再次封装时候遵循的准则不同。
ICMP是Ping命令经常用到的协议。Ping命令不是什么特别神秘的东西，是一个程序员编写的一个exe应用程序，你的电脑控制台之所有能够使用这个程序，是因为你的电脑上安装了这个exe，而且在path里边设置了这个程序的路径。ICMP全称是报文控制协议。通过上边的图片可以看出，应用层的Ping工具，使用Ping协议，直接跳过运输层，调用了网络层的ICMP协议。ICMP数据包里边内容，都是关于目的主机的一些信息，因此可以用于远程判断一台主机是否存在于网络上。ping程序是对两个系统连通性进行测试的基本工具。它只利用ICMP回显请求和回显应答报文，而不用经过传输层TCP/UDP。Ping服务器一般在内核中实现ICMP的功能。
网络上一台主机的可达性不仅仅取决于IP层是否可达，还要取决于使用何种协议以及端口号。就比如说，一台主机确实存在于互联网上边，而且一台Client向这台主机使用Ping工具发起ICMP协议包，这些数据包也准确到达了主机。主机在接收到这些数据包之后，从链路层传到网络层一层层拆去包装进行解析，但是主机的操作系统从网络层再往上解析的时候，发现了Ping的端口为6666（假设该主机封闭了该端口），就不会做出反应，而且默默的把这些数据吞了。那么在Client看来，发出去的数据包失联了，会认为这个主机找不到。
所以，总结一下Ping不同可能的原因：主机不在线，比如说关机了或者拔掉网线了。还有就是网络防火墙或者IP策略，会对ICMP报文进行过滤，ping命令无法回应，还有就是主机本身的一些策略，会过滤掉ICMP数据包。
(个人感觉操作系统以及网卡是这样工作的，所有的网络数据都是从一个入口进来的，进来之后操作系统与网卡相关的部件就开始从最底层开始解析这些二进制的数据包，一层层的拆包，组装，然后分析，直到IP层的时候，会对IP数据包进行分析，然后进行TCP层的分析，这时候就发现了端口号这个概念，那么会根据端口号的不同，把这些数据存储在不同的缓冲区域，每个缓冲区域属于一个指定的应用程序（以端口号作为标识）。最终应用程序会从自己的缓冲区域来进行网络数据的读取。)
关于TCP的通信机制。
当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。这种对字节流的处理方式与Unix操作系统对文件的处理方式很相似。Unix的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对Unix的内核来说，它无法区分一个二进制文件与一个文本文件。
(这里说一句题外话，就是ASCII码与二进制文件的问题。最终保存在计算机硬盘上的数据都是二进制数据，那么这个二进制数据是怎么来的，这是一个问题。就拿txt文本文件来说，其存储方式就是根据ASCII码将文本内容转换成相应的数字，然后用二进制的形式保存并且存储。但是对于word等文件来说，比较复杂，有专门的软件比如说Office来处理，并且有一定的算法来生成这些二进制。所以这就是为什么Word文件必须要用Office软件来打开。Notepad是操作系统自带的，如果用Notepad去打开word ,那么notepad就会根据ASCII码的方式去解析，最终发现要么无法解析出来字符，要么解析出来的字符是乱码。)
每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接。一个IP地址和一个端口号也称为一个插口socket.
既然一个TCP连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN，它必须通知应用层另一端几经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。
与Telnet类似，FTP最早的设计是用于两台不同的主机，这两个主机可能运行在不同的操作系统下、使用不同的文件结构、并可能使用不同字符集。但不同的是，Telnet获得异构性是强制两端都采用同一个标准：使用7比特ASCII码的NVT。而FTP是采用另一种方法来处理不同系统间的差异。FTP支持有限数量的文件类型（A S C II，二进制，等等）和文件结构（面向字节流或记录）。
在一次HTTP请求中，form表单的数据与上传的文件数据有什么不同？
表单数据是根据ASCII码转换成的二进制，而上传文件的时候，就是直接读取的计算机硬盘上的二进制数据。比如说上传一个Word文件，服务器端接收到的会是一大段二进制数据。其实文件在客户端存储的时候就是一大段二进制码，那么这个二进制码是怎么生成的？那么就要问微软的Office客户端了，是它根据一定的方式生成的二进制码然后存在了硬盘上。所以，这就是为什么，一个exe生成的文件另外的exe打不开，因为使用的解码方式不一样，不知道怎么去分析这么一大堆的二进制码，然后生成需要字符串展现给用户。
端口号，不是说一个真正存在的实体，或者说在网卡上有个端口啥的。其实端口号就是一个简单的数字标识，用于区分不同的应用程序，有点类似于应用程序的ID，因为网络数据到达了一个主机上边，怎么知道这个数据是给哪个应用程序的呢，这时候端口号就起作用了。前面已经指出过， TCP和UDP采用16bit的端口号来识别应用程序。那么这些端口号是如何选择的呢？服务器一般都是通过知名端口号来识别的。例如，对于每个TCP/IP实现来说，FTP服务器的TCP端口号都是2 1，每个Telnet服务器的TCP端口号都是2 3，每个TFTP (简单文件传送)服务器的UDP端口号都是69。
客户端通常对它所使用的端口号并不关心，只需保证该端口号在本机上是唯一的就可以了。客户端口号又称作临时端口号（即存在时间很短暂）。这是因为它通常只是在用户运行该客户程序时才存在，而服务器则只要主机开着的，其服务就运行。
网络层（ IP）提供点到点的服务，而运输层（ T C P和U D P）提供端到端的服务。
在TCP/IP协议族中，网络层IP提供的是一种不可靠的服务。也就是说，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。而另一方面， TCP在不可靠的IP层上提供了一个可靠的运输层。为了提供这种可靠的服务， TCP采用了超时重传、发送和接收端到端的确认分组等机制。由此可见，运输层和网络层分别负责不同的功能。
以前一直搞不懂，为什么IP层是不可靠的，而TCP是建立在IP的基础上的，却是可靠的呢？因为做了一些冗余的操作来保证可靠。Telnet和Rlogin这两个交互应用要求最小的传输时延，因为人们主要用它们来传输少量的交互数据。另一方面，FTP文件传输则要求有最大的吞吐量。
同一个HTML页面，从服务器端发送到客户端浏览器，首先是根据HTTP协议，组装字符串，组装成一次请求回复，这个回复的字符串包括header，body等。然后这个字符串会被转成二进制数据，然后给TCP层去分解，然后TCP层交给IP层，拆解成多个IP数据包。这时候这些包是无序的，不一定哪个包先到达。最终这些包再组成文件，如img,css,js文件。这就是为什么图片渲染出来的顺序不一样。
IP层的下一层是数据链路层，我们也可以理解为以太网层或者令牌网。当一台主机把以太网数据帧发送到位于同一局域网上的另一台主机时，是根据48bit的以太网地址来确定目的接口的。设备驱动程序从不检查IP数据报中的目的IP地址。ARP为IP地址到对应的硬件地址之间提供动态映射。我们之所以用动态这个词是因为这个过程是自动完成的，一般应用程序用户或系统管理员不必关心。
在硬件层次上进行的数据帧交换必须有正确的接口地址。但是，TCP/IP有自己的地址：32 bit的IP地址。知道主机的IP地址并不能让内核发送一帧数据给主机。内核（如以太网驱动程序）必须知道目的端的硬件地址才能发送数据。ARP的功能是在32bit的IP地址和采用不同网络技术的硬件地址之间提供动态映射。
获取字符串的ASCII码
string A = "Hello World";
byte[] data = Encoding.ASCII.GetBytes(A);
一次Http请求，会建立一个TCP连接，然后将内容切割，分组打包，最后发送到服务器。
以前有个疑问，就是总觉得进行TCP通信的A与B之间有个管道。如果A在发消息的时候，B也发送消息，那么内容在管道之中不就冲突了么。但是这种想法是错误的。A与B之间根本没有管道，是通过IP层这种路由方式来进行数据包的转换的，发送方与接收方根本都没有指定的路线。发送与接收都是在不同的缓冲区，一般发消息的一方会在发送的内容中添加一个标识符，告诉接收方这次这一批的数据发送完了，你去处理吧，处理完了给我个回复。
当我们写代码的时候，有个读取网络数据的read方法，以前我一直以为是去网络上都数据。这是错误的，这个read呢，就是去从缓冲区读取已经被操作系统或者网卡拆箱并且还原了的数据，把这个数据读取到程序的内存中。
为什么TCP建立连接会花费开销？
这里并不是说要占用很多的互联网上的带宽，这里的花销主要是指电脑上的资源消耗。建立TCP连接的时候，电脑要做很多的准备工作，建立相应的缓冲区域，根据端口号建立存储区域，还有就是IP是不可靠的，TCP要想办法找出空间来存储一些额外的东西来保证可靠性，这都是开销。
还是那句话，建立TCP通道，其实根本没有通道，走的是IP路由，建立通道主要是在电脑内存上开辟出相应的空间。TCP连接一直存在，说明那块相应的缓存区域一直没有被回收。
A与B之间是怎么建立起TCP连接的？
这个就涉及到了3次握手机制。因为B机器上有程序在时刻监视着所有的IP数据包，一旦检测到数据包中含有3次握手的内容，便会打开一个连接，然后通过身份验证等机制，最终建立起TCP连接。