大规模，高并发网站开发经验都有哪些

高并发量网站解决方案

一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃。

在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadMole，保证更高的系统消耗和执行效率。

3、数据库集群、库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和ENet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

（1）、硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

(2)、软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

最新：CDN加速技术

CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。

CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。

CDN的类型特点

CDN的实现分为三类：镜像、高速缓存、专线。

镜像站点（MirrorSite），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。

高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。

CDN服务一般会在全国范围内的关键节点上放置缓存服务器。

专线，让用户直接访问数据源，可以实现数据的动态同步。

CDN的实例

举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。

当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。

通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。

由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。

辛辛苦苦找到的，够详细吧？

1 引言

随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、**播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统，或者是针对流媒体数据的编码方式所进行的研究。本文对流媒体服务器技术的研究重点在于如何建立一个服务器，并且在实现流媒体传输的两个基本协议RTP/RTCP的基础上构建一个基本的流媒体服务器。

2 流媒体技术简介

21 “流”的定义

现在网上传输视频、音频主要有下载（Download）和流式传输（Streaming）两种方式。流式传输是连续传送视/音频信号，当流媒体在客户机播放时其余部分在后台继续下载。流式传输有顺序流式传输(Progressive Streaming)和实时流式传输(Realtime Streaming)两种方式。实时流式传输是实时传送，特别适合现场事件，实时流式传输必须匹配连接带宽，这意味着图像质量会因网络速度降低而变差,以减少对传输带宽的需求。“实时”的概念是指在一个应用中数据的交付必须与数据的产生保持精确的时间关系。

在Internet中使用流式传输技术的连续时基媒体就称为流媒体，通常也将其视频与音频称为视频流和音频流。实现流式传输一般都需要专用服务器和播放器。

22 流媒体系统组件

流媒体是由各种不同软件构成的，这些软件在各个不同层面上互相通信，基本的流媒体系统包含以下3个组件：

播放器（Player），用来播放流媒体的软件。

服务器（Server），用来向用户发送流媒体的软件。

编码器（Encode），用来将原始的音频视频转化为流媒体格式的软件。

这些组件之间通过特定的协议互相通信，按照特定的格式互相交换文件数据。有些文件中包含了由特定编解码器解码的数据，这种编解码器通过特定算法压缩文件的数据量。

3 流媒体服务器的基本功能和服务方式

31 流媒体服务器的主要功能

（1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信（这种通信是必需的，因为客户可能随时暂停或快放一个文件）。

（2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。

（3）可提供其他额外功能，如：数字权限管理（DRM），插播广告，分割或镜像其他服务器的流，还有组播。

32 流媒体服务器的服务方式

（1）单播。在客户端与媒体服务器之间建立一个单独的数据通道，从1台服务器送出的每个数据包只能传送给1个客户机。

（2）组播。在以组播技术构建的网络上，允许路由器一次将数据包复制到多个通道上。

（3）点播与广播。点播连接是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，用户可以开始、停止、后退、快进或暂停流。广播指的是用户被动地接收流，在广播过程中，数据包的单独一个拷贝将发送给网络上的所有用户，客户端接收流，但不能控制流。

4 构建流媒体服务器

41 RTP/RTCP协议简介

实时传输协议RTP（Realtime Transport Protocol）：是针对Internet上多媒体数据流的一个传输协议, 由IETF(Internet工程任务组)作为RFC1889发布。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。

实时传输控制协议RTCP（Realtime Transport Control Protocol）：负责管理传输质量在当前应用进程之间交换控制信息。在RTP会话期间，各参与者周期性地传送RTCP包，包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，能以有效的反馈和最小的开销使传输效率最佳化，故特别适合传送网上的实时数据。

RTCP主要有4个功能:

（1）用反馈信息的方法来提供分配数据的传送质量，这种反馈可以用来进行流量的拥塞控制，也可以用来监视网络和用来诊断网络中的问题；

（2）为RTP源提供一个永久性的CNAME（规范性名字）的传送层标志，因为在发现冲突或者程序更新重启时SSRC(同步源标识)会变，需要一个运作痕迹，在一组相关的会话中接收方也要用CNAME来从一个指定的与会者得到相联系的数据流（如音频和视频）；

（3）根据与会者的数量来调整RTCP包的发送率；

（4）传送会话控制信息，如可在用户接口显示与会者的标识，这是可选功能。

42 RTP/RTCP工作过程

工作时，RTP协议从上层接收流媒体信息码流（如H263），装配成RTP数据包发送给下层，下层协议提供RTP和RTCP的分流。如在UDP中， RTP使用一个偶数号端口，则相应的RTCP使用其后的奇数号端口。RTP数据包没有长度限制，它的最大包长只受下层协议的限制。

43 服务器的算法

服务器软件模型主要有两种，即并发服务器和循环服务器。循环服务器(Iterative Server)是指在一个时刻只处理一个请求的服务器。并发服务器(Concurrent Server)是指在一个时刻可以处理多个请求的服务器。事实上，多数服务器没有用于同时处理多个请求的冗余设备，而是提供一种表面上的并发性，方法是依靠执行多个线程，每个线程处理一个请求，从客户的角度看，服务器就像在并发地与多个客户通信。

由于流媒体服务时间的不定性和数据交互实时性的请求，流媒体服务器一般采用并发服务器算法。本文构建了一个基本的流媒体服务器，能够同时响应多个用户的请求，把本地硬盘流媒体文件或实时数据流（H263格式）发送给用户。在应用中，把客户分为请求实时数据的实时客户和请求文件数据的文件客户两类。主要算法为：

（1）打开设备，分配资源。当设备准备好时，创建一个RTP实时服务线程和一个RTCP实时服务线程。

（2）创建一个UDP套接字并将其绑定到所提供服务的地址之上。

（3）反复调用接收模块，接收来自客户的RTCP报告，根据其类型做出响应。对新实时客户的请求，把客户地址添加到实时服务的客户列表中，对新文件客户的请求，则创建一个新RTP文件服务线程和一个新RTCP文件服务线程；对已经在服务中的客户则根据RTCP报告的内容调整服务。

RTP实时服务线程1：初始化客户列表和RTP首部。

RTP实时服务线程2：从设备读取媒体数据，把数据发送给实时服务列表中的客户。

RTP实时服务线程3：更新RTP首部和统计数据。

RTP实时服务线程4：计算延时，重复第二步。

RTCP实时服务线程1：初始化RTCP首部。

RTCP实时服务线程2：发送发送方报告给实时服务列表中的客户。

RTCP实时服务线程3：计算延时，重复第二步。

RTP文件服务线程1：初始化RTP首部。

RTP文件服务线程2：从文件读取媒体数据，把数据发送给客户。

RTP文件服务线程3：更新已发送数据的统计信息，为生成发送方报告做准备。

RTP文件服务线程4：计算延时，调整发送速度，正常情况下开始重复第二步。

RTCP文件服务线程1：初始化RTCP首部，发送一个源描述(SDES)报文给客户。

RTCP文件服务线程2：根据已发送数据的统计信息生成发送方报告，发送给客户。

RTCP文件服务线程3：计算延时，正常情况下开始重复第一步。

5 流媒体服务器实现中应注意的问题

51 会话和流的两级分用

一个RTP会话(Session)包括传给某个指定目的地对(Destination Pair)的所有通信量，发送方可能包括多个。而从同一个同步源发出的RTP分组序列称为流(Stream),一个RTP会话可能包含多个RTP流。一个 RTP分组在服务器端发送出去的时候总是要指定属于哪个会话和流，在接收时也需要进行两级分用，即会话分用和流分用。只有当RTP使用同步源标识 (SSRC)和分组类型(PTYPE)把同一个流中的分组组合起来，才能够使用序列号(Sequence Number)和时间戳(Timestamp)对分组进行排序和正确回放。

52 多线程的管理

并发服务器模式要求用多线程来提供服务，所以多线程的管理十分重要。在本文构建的服务器中，不同客户的请求和反馈都由服务器的主线程处理，由于实时数据的独有性，不同实时客户可以共用一个RTP实时服务线程和一个RTCP实时服务线程，这样可以大大减小服务器的负担，而每个文件客户由于请求的文件不同，相应地对速度和开始时间的要求都可能不同，所以需要有自己独有的RTP文件服务线程和RTCP文件服务线程。

RTP服务线程负责把实时数据流发送给客户， RTCP服务线程根据RTP线程的统计数据，产生发送方报告给客户。RTP线程和RTCP线程之间通过一段共享内存交互统计数据，对共享内存必须设置互斥体进行保护，防止出现错误读写。在这种方式下，服务器可以根据每个用户的不同请求和具体情况方便地提供不同的服务。

53 时间戳的处理

时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间 (Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。

RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。

在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。

54 媒体数据发送速度的控制

由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。

55 多种流同步

RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。

6 结论

流媒体技术的应用日益广泛，对流媒体技术的研究具有很大的实际意义,本文通过对RTP/RTCP协议的研究，分析流媒体服务器的一般功能和结构，给出构建一个基本的流媒体服务器的实现方案，实验证明可以同时满足多个实时和文件客户的要求,并已经应用于一个远程监控系统中

IIS连接数指并发连接数要分几种情况：

1用户打开你的页面，就算停留在页面没有对服务器发出任何请求，那么在用户打开一面以后的20分钟内也都要算一个在线，就是说你50人的网站20分钟内可以接受不同用户打开50个页面。

2上面B的情况用户继续打开同一个网站的其他页面，那么在线人数按照用户最后一次点击（发出请求）以后的20分钟计算，在这个20分钟内不管用户怎么点击（包括新窗口打开）都还是一人在线。

3当你的页面内存在框架（IFrame），那么每多一个框架就要多一倍的在线！因为这相当于用户同一时间向服务器请求了多个页面。

4当用户打开页面然后正常关闭浏览器，用户的在线人数也会马上清除。

防火墙并发连接数：

并发连接数是指防火墙或代理服务器对其业务信息流的处理能力，是防火墙能够同时处理的点对点连接的最大数目，它反映出防火墙设备对多个连接的访问控制能力和连接状态跟踪能力，这个参数的大小直接影响到防火墙所能支持的最大信息点数。

并发连接数是衡量防火墙性能的一个重要指标。在目前市面上常见防火墙设备的说明书中大家可以看到，从低端设备的500、1000个并发连接，一直到高端设备的数万、数十万并发连接，存在着好几个数量级的差异。那么，并发连接数究竟是一个什么概念呢？它的大小会对用户的日常使用产生什么影响呢？要了解并发连接数，首先需要明白一个概念，那就是“会话”。这个“会话”可不是我们平时的谈话，但是可以用平时的谈话来理解，两个人在谈话时，你一句，我一句，一问一答，我们把它称为一次对话，或者叫会话。同样，在我们用电脑工作时，打开的一个窗口或一个Web页面，我们也可以把它叫做一个“会话”，扩展到一个局域网里面，所有用户要通过防火墙上网，要打开很多个窗口或Web页面发（即会话），那么，这个防火墙，所能处理的最大会话数量，就是“并发连接数”。

像路由器的路由表存放路由信息一样，防火墙里也有一个这样的表，我们把它叫做并发连接表，是防火墙用以存放并发连接信息的地方，它可在防火墙系统启动后动态分配进程的内存空间，其大小也就是防火墙所能支持的最大并发连接数。大的并发连接表可以增大防火墙最大并发连接数，允许防火墙支持更多的客户终端。尽管看上去，防火墙等类似产品的并发连接数似乎是越大越好。但是与此同时，过大的并发连接表也会带来一定的负面影响：

1并发连接数的增大意味着对系统内存资源的消耗

以每个并发连接表项占用300B计算，1000个并发连接将占用300B×1000×8bit/B≈23Mb内存空间，10000个并发连接将占用23Mb内存空间，100000个并发连接将占用230Mb内存空间，而如果真的试图实现1000000个并发连接的话那么，这个产品就需要提供224Gb内存空间！

2并发连接数的增大应当充分考虑CPU的处理能力

CPU的主要任务是把网络上的流量从一个网段尽可能快速地转发到另外一个网段上，并且在转发过程中对此流量按照一定的访问控制策略进行许可检查、流量统计和访问审计等操作，这都要求防火墙对并发连接表中的相应表项进行不断的更新读写操作。如果不顾CPU的实际处理能力而贸然增大系统的并发连接表，势必影响防火墙对连接请求的处理延迟，造成某些连接超时，让更多的连接报文被重发，进而导致更多的连接超时，最后形成雪崩效应，致使整个防火墙系统崩溃。

3物理链路的实际承载能力将严重影响防火墙发挥出其对海量并发连接的处理能力

虽然目前很多防火墙都提供了10/100/1000Mbps的网络接口，但是，由于防火墙通常都部署在Internet出口处，在客户端PC与目的资源中间的路径上，总是存在着瓶颈链路——该瓶颈链路可能是2Mbps专线，也可能是512Kbps乃至64Kbps的低速链路。这些拥挤的低速链路根本无法承载太多的并发连接，所以即便是防火墙能够支持大规模的并发访问连接，也无法发挥出其原有的性能。

有鉴于此，我们应当根据网络环境的具体情况和个人不同的上网习惯来选择适当规模的并发连接表。因为不同规模的网络会产生大小不同的并发连接，而用户习惯于何种网络服务以及如何使用这些服务，同样也会产生不同的并发连接需求。高并发连接数的防火墙设备通常需要客户投资更多的设备，这是因为并发连接数的增大牵扯到数据结构、CPU、内存、系统总线和网络接口等多方面因素。如何在合理的设备投资和实际上所能提供的性能之间寻找一个黄金平衡点将是用户选择产品的一个重要任务。按照并发连接数来衡量方案的合理性是一个值得推荐的办法。

以每个用户需要105个并发连接来计算，一个中小型企业网络（1000个信息点以下，容纳4个C类地址空间）大概需要105×1000=10500个并发连接，因此支持20000～30000最大并发连接的防火墙设备便可以满足需求；大型的企事业单位网络（比如信息点数在1000～10000之间）大概会需要105000个并发连接，所以支持100000～120000最大并发连接的防火墙就可以满足企业的实际需要; 而对于大型电信运营商和ISP来说，电信级的千兆防火墙（支持120000～200000个并发连接）则是恰当的选择。为较低需求而采用高端的防火墙设备将造成用户投资的浪费，同样为较高的客户需求而采用低端设备将无法达到预计的性能指标。利用网络整体上的并发连接需求来选择适当的防火墙产品可以帮助用户快速、准确的定位所需要的产品，避免对单纯某一参数“愈大愈好”的盲目追求，缩短设计施工周期，节省企业的开支。从而为企业实施最合理的安全保护方案。

在利用并发连接数指标选择防火墙产品的同时，产品的综合性能、厂家的研发力量、资金实力、企业的商业信誉和经营风险以及产品线的技术支持和售后服务体系等都应当纳入采购者的视野，将多方面的因素结合起来进行综合考虑，切不可盲目的听信某些厂家广告宣传中的大并发连接的宣传，要根据自己业务系统、企业规模、发展空间和自身实力等因素多方面考虑。

来源

三次握手流程：

为何不采用两次握手

四次挥手流程：

为何需要进入 TIME-WAIT 等待 2 MSL 时间才进入close状态

为何握手需要三次而挥手需要四次

三次握手和四次挥手简单举例

三次握手

四次挥手

报文格式

来源

HTTP的请求报文包括： 请求行(request line) 、 请求头部(header) 、 空行 和 请求数据(request data) 四个部分组成。

来源

请求行 包括： 请求方法，URL(包括参数信息)，协议版本这些信息（GET /admin_ui/rdx/core/images/closepng HTTP/11）

请求头部(Header) 是一个个的key-value值，比如

请求数据 ：GET方法没有携带数据， POST方法会携带一个body

HTTP的响应报文包括：状态行，响应头，空行，数据(响应体)

来源

状态行 包括：HTTP版本号，状态码和状态值组成。

响应头 类似请求头，是一系列key-value值

空白行：同上，响应报文也用空白行来分隔header和数据

响应体 ：响应的data，本例中是一段HTML

数字中的第一位指定了响应类别，后两位无分类，响应类别有一下5种：

状态码分类表

2xx （3种）

3xx （5种）

4xx （4种）

5xx （2种）

11 长连接(Persistent Connection) HTTP11支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP11中默认开启长连接keep-alive，一定程度上弥补了HTTP10每次请求都要创建连接的缺点。HTTP10需要使用keep-alive参数来告知服务器端要建立一个长连接。

12 节约带宽 HTTP10中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP11支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。

13 HOST域 在HTTP10中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP10没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP11的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。

14缓存处理 在HTTP10中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP11则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

21 多路复用

HTTP20使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP11大了好几个数量级。HTTP11也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

来源

22 头部压缩

在HTTP11中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

HTTP11不支持header数据的压缩，HTTP20使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

HTTP是明文传输，整个过程完全透明，任何人都能够在链路中截取、修改或者伪造请求，数据不具有可靠性。因此有了https

HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

参考：

https://juejinim/entry/5981c5df518825359a2b9476

一、问题描述

不同主机之间通讯，必须依赖套接字，而端口号是套接字的标识（开始是这样认为的），那么假设web服务器进程，开启了80端口号（即监听80端口号），接着客户端浏览器，打开任意端口，发起TCP连接请求，服务器80端口监听到请求，建立TCP连接，最后通过客户端套接字和服务器套接字进行通信，那么其他用户怎么办？ 80端口也被占用，改如何建立TCP连接？现实中大家发送http请求好像都可以使用一样的端口，如80。

二、问题解决

首先，明确几点：

1、TCP套接字的唯一标识是一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）

2、TCP创建连接，会进行“三次握手”，

我们这里暂且把TCP建立连接的报文段称为：称为TCP连接

把TCP承载请求数据的报文段称为：TCP请求

客户端浏览器和web服务器的通信过程是这样的：

在建立连接阶段：

浏览器进程打开任意端口，所有的浏览器都是将TCP连接报文，发送给服务器进程监听的端口（如：80），服务器接受到请求，为每个请求创建新的套接字（依据请求报文的源ip,源端口号和自己的ip、端口号）

在发送http请求阶段：

此时连接已经建立，承载了 HTTP请求信息的TCP请求报文会发送到对应的套接字

因此： 多个不同的套接字可以拥有相同的目的端口号80，由于源ip或端口号不同，TCP套接字就可以唯一标识，通信就可以进行。

同时，一个端口号只能被一个进程所监听

举一反三：其实所有使用TCP的应用程序对的通信都是一样的，分为建立连接和发送数据阶段。

在建立连接时，对于 客户端TCP套接字还没有形成，服务器端进程也是如此，它只是监听80端口而已，把所有目的端口号为80的TCP报文段统统接收，然后去处理，即建立套接字，为套接字分配处理进程。当连接建立时，对应着服务器、客户端套接字的形成，之后的通信，不会将TCP报文段在发送给监听80端口的服务器进程，而是发给与连接对应的套接字，它的目的端口号也是80,但他只是套接字的一部分。

对于服务器进程也是不一样的：一个专门用于建立连接，它监听端口，创建用于连接的套接字

一个专门用于处理请求，通过新建立的套接字发送和接收请求

最后再次总结：

一个端口同一时间只能bind给一个SOCKET。就是同一时间一个端口只可能有一个监听线程

为什么一个端口能建立多个TCP连接，同一个端口也就是说 server ip和server port 是不变的。那么只要[client ip 和 client port]不相同就可以了。能保证接唯一标识[server ip, server port, client ip, client port]的唯一性。

端口号不是套接字的唯一标识。另外，UDP套接字是（目的ip地址，目的端口号）。