Http协议与TCP协议简单理解
在C#编写代码，很多时候会遇到Http协议或者TCP协议，这里做一个简单的理解。
tcp ip协议在哪里设置TCP协议对应于传输层，而HTTP协议对应于应用层，从本质上来说，二者没有可比性。Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Ht tp请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，是一种无状态的连接。所谓的无状态，是指浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。如果是一个连接的话，服务器进程中就能保持住这个连接并且在内存中记住一些信息状态。而每次请求结束后，连接就关闭，相关的内容就释放了，所以记不住任何状态，成为无状态连接。
随着时间的推移，html页面变得复杂了，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次tcp连接就显得低效了。因此Keep-Aliv e 被提出用来解决效率低的问题。从HTTP/1.1起，默认都开启了K eep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接Keep-Aliv e不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。虽然这里使用T CP连接保持了一段时间，但是这个时间是有限范围的，到了时间点依然是会关闭的，
所以我们还把其看做是每次连接完成后就会关闭。后来，通过Sessi on, Cookie等相关技术，也能保持一些用户的状态。但是还是每次都使用一个连接，依然是无状态连接。
以前有个概念很容忍搞不清楚。就是为什么Ht tp是无状态的短连接，而TCP是有状态的长连接？Http不是建立在TCP的基础上吗，为什么还能是短连接？现在明白了，Http就是在每次请求完成后就把TCP连接关了，所以是短连接。而我们直接通过Socket编程使用TC P协议的时候，因为我们自己可以通过代码区控制什么时候打开连接什么时候关闭连接，只要我们不通过代码把连接关闭，这个连接就会在客户端和服务端的进程中一直存在，相关状态数据会一直保存着。
在C#中会有Sock et，实际上sock et是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如creat e、listen、connect、accept、send、read和wr ite等等。
比较形象的描述：HTTP是轿车，提供了封装或者显示数据的具体形式;Socket是发动机，提供了网络通信的能力。对于从C#编程的角度来讲，为了方便，你可以直接选择已经制造好的轿车Http来与服务器交互。但是有时候往往因为环境因素或者其他的一些定制的请求，必须要使用TCP协议，这时就需要使用Socket编程，然后自己去处理获取的数据。就像是你用已有的发动机，自己造了一辆卡车，去从服务器交互。
HTTP/1.0和HTTP/1.1都把TCP作为底层的传输协议。HTTP客户首先发起建立与服务器TCP连接。一旦建立连接，浏览器进程和服务器进程就可以通过各自的套接字来访问TCP。如前所述，客户端套接字是客户进程和T CP连接之间的“门”，服务器端套接字是服务器进程和同一TCP连接之间的“门”。客户往自己的套接字发送HT TP请求消息，也从自己的套接字接收HTT P响应消息。类似地，服务器从自己的套接字接收H TTP请求消息，也往自己的套接字发送HTT P响应消息。客户或服务器一旦把某个消息送入各自的套接字，这个消息就完全落入TCP的控制之中。TCP给HTT P 提供一个可靠的数据传输服务；这意味着由客户发出的每个H TTP请求消息最终将无损地到达服务器，由服务器发出的每个HTTP响应消息最终也将无损地到达客户。
C#代码连接远程数据库用的是T CP协议。每次new一个conne ction的时候，connect ion.open就打开了这个TCP连接。connect ion.Close的时候就关闭了这个连接。FTP的底层也是TCP，不过是长连接的。传输大文件比较快。需要看具体场景。在服务器端，如果程序是采取的长连接的方式，那么就能控制同时连接到这个服务器的连接个数，防止同时有多个连接。但是采取短连接的方式，那么就不能控制同时连接到这个服务器上的连接的个数，这也是一个优点，可以同时处理大量连接请求。但是如果连接请求量太大的话，可能造成服务器停止工作。
WebServ ice不需要连接，一秒中至少可以支持上万/十万的请求，每次请求然后释放，没有空余的内存消耗。一般不会限制同时连接的个数，这是优势。Message Queue需要建立连接，支持上千的连接就很
吃力了。因为每个连接即使没有在请求数据，也会在内存中占用一定的空间存储。会限制，比如SQL Serv er数据库服务器，一般最多同时连接16个。
Http协议一定通过指定的端口，80，所以一般计算机上不会限制这个端口，所以Http协议能够顺利通过所有机器上的防火墙。而使用Sock et编程的话，就需要自己指定特定的端口，那么很可能这个端口是在某个环境中禁用的，那么就无法穿透防火墙。IIS使用的是80端口，也就是这个程序一直在监听着这个端口。一旦发现有人要建立到这个端口的连接，他就会响应，然后建立连接。这里说的连接都是短连接。所以你对服务器上的网址的请求，都是通过80端口送到网站程序的。然后通过这个端口发送的客户端浏览器。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论