TCP协议相应于传输层，而HTTP协议相应于应用层。从本质上来说，二者没有可比性。
Http协议是建立在TCP协议基础之上的，当浏览器须要从server获取网页数据的时候。会发出一次Http请求。Http会通过TCP建立起一个到server的连接通道，当本次请求须要的数据完成后，Http会马上将TCP连接断开。这个过程是非常短的。
所以Http连接是一种短连接，是一种无状态的连接。
所谓的无状态，是指浏览器每次向server发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。假设是一个连接的话。server进程中就能保持住这个连接而且在内存中记住一些信息状态。而每次请求结束后。连接就关闭，相关的内容就释放了。所以记不住不论什么状态，成为无状态连接。随着时间的推移，html页面变得复杂了。里面可能嵌入了非常多图片，这时候每次訪问图片都须要建立一次tcp连接就显得低效了。
因此Keep-Alive被提出用来解决效率低的问题。从HTTP/1.1起。默认都开启了Keep-Alive。保持连接特性，简单地说，当一个网页打开完毕后，client和server之间用于传输HTTP数据的TCP连接不会关闭，假设client再次訪问这个server上的网页，会继续使用这一条已经建立的连接Keep-Alive不会永久保持连接，它有一个保持时间。能够在不同的server软件（如Apache）中设定这个时间。
尽管这里使用TCP连接保持了一段时间，可是这个时间是有限范围的，到了时间点依旧是会关闭的，所以我们还把其看做是每次连接完毕后就会关闭。
后来。通过Session, Cookie等相关技术，也能保持一些用户的状态。
可是还是每次都使用一个连接，依旧是无状态连接。
曾经有个概念非常容忍搞不清楚。就是为什么Http是无状态的短连接，而TCP是有状态的长连接？Http不是建立在TCP的基础上吗，为什么还能是短连接？如今明确了，Http就是在每次请求完毕后就把TCP连接关了。所以是短连接。而我们直接通过Socket编程使用TCP协议的时候，由于我们自己能够通过代码区控制什么时候打开连接什么时候关闭连接，仅仅要我们不通过代码把连接关闭。这个连接就会在client和服务端的进程中一直存在，相关状态数据会一直保存着。
在C#中会有Socket，实际上socket是对TCP/IP协议的封装，Socket本身并非协议。而是一个调用接口(API)。Socket的出现仅仅是使得程序猿更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象。从而形成了我们知道的一些最主要的函数接口，比方create、listen、connect、accept、send、read和write等等。
比較形象的描写叙述：HTTP是轿车。提供了封装或者显示数据的详细形式;Socket是发动机，提供了网络通信的能力。对于从C#编程的角度来讲，为了方便，你能够直接选择已经制造好的轿车Http来与server交互。可是有时候往往由于环境因素或者其它的一些定制的请求，必需要使用TCP协议。这时就需要使用Socket编程，然后自己去处理获取的数据。
就像是你用已有的发动机。自己造了一辆卡车，去从server交互。
HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。
HTTP客户首先发起建立与serverTCP连接。一旦建立连接，浏览器进程和server进程就能够通过各自的套接字来訪问TCP。如前所述，client套接字是客户进程和TCP连接之间的“门”，server端套接字是server进程和同一TCP连接之间的“门”。
客户往自己的套接字发送HTTP请求消息。也从自己的套接字接收HTTP响应消息。类似地，server从自己的套接字接收HTTP请求消息，也往自己的套接字发送HTTP响应消息。客户或server一旦把某个消息送入各自的套接字，这个消息就全然落入TCP的控制之中。TCP给HTTP提供一个可靠的传输数据服务;这意味着由客户发出的每一个HTTP请求消息终于将无损地到达server，由server发出的每一个HTTP响应消息终于也将无损地到达客户。C#代码连接远程数据库用的是TCP协议。每次new 一个connection的时候，connection.open就打开了这个TCP连接。connection.Close的时候就关闭了这个连接。
FTP的底层也是TCP。 只是是长连接的。
传输大文件比較快。 须要看详细场景。
在server端，假设程序是採取的长连接的方式。那么就能控制同一时候连接到这个server的连接个数，防止同一时候有多个连接。可是採取短连接的方式，那么就不能控制同一时候连接到这个server上的连接的个数，这也是一个长处，能够同一时候处理大量连接请求。可是假设连接请求量太大的话，可能造成server停止工作。
WebService不须要连接，一秒中至少能够支持上万/十万的请求，每次请求然后释放，没有空余的内存消耗。一般不会限制同一时候连接的个数。这是优势。Message Queue须要建立连接。 支持上千的连接就非常吃力了。由于每一个连接即使没有在请求数据，也会在内存中占用一定的空间存储。会限制，比方SQL Server数据库server。一般最多同一时候连接16个。
而使用Socket编程的话。就须要自己指定特定的port，那么非常可能这个port是在某个环境中禁用的，那么就无法穿透防火墙。
IIS使用的是80port，也就是这个程序一直在监听着这个port。一旦发现有人要建立到这个port的连接，他就会响应，然后建立连接。这里说的连接都是短连接。
所以你对server上的网址的请求，都是通过80port送到站点程序的。然后通过这个port发送的client浏览器。