这部分概述了HTTP协议的属性，包括提高互通性、 减少暴露已知的安全漏洞或者减少执行变异的可能。
HTTP/2的连接是持久性的。 为了获得最佳的性能，在确定与服务器没有进一步的连接必要之前客户端将不会关闭连接（例如：当用户导航到其他特定的网页时这个连接就会关闭），或者直到服务器端关闭连接之前。
客户端不应该给一个给定的主机和端口号打开多个HTTP/2连接，其中这个主机来源于一个选定替代服务(参见：ALT-SVG)或者配置代理的统一资源标识符(URI)。
客户端可以创建额外的连接作为替代，或者取代快要耗尽的可用流标识符空间（参见：Section 5.1.1)，或者为TLS连接刷新密钥，或者替换遇到的错误连接（参见: Section 5.4.1）。
一个客户端可以针对相同的IP地址和TCP端口号用不同的服务器端名称标识符或者用不同的TCL客户端证书创建多个连接，但是应该避免用相同的配置创建多个连接。
服务器端被鼓励尽可能长时间的保持打开的连接，但是在必要的情况下要关闭空余的连接。当任意一个端口选择关闭传输层的TCP连接时，决定关闭的终端应该首先发送一个超时帧，这样两个终端都能可靠的确定之前发送的帧是否已经被处理、“优雅”的完成或者终止任何剩余的必要任务。
连接到源服务器的连接，无论是直接或者通过由CONNECT方法(参见： Section 8.3)建立的隧道连接,都可能重复使用于多个不同URL权限请求组件。只要源服务器是权威的，连接就可以被复用（参见： Section 10.1）。对于没有TLS的TCP连接，这取决于对同一个IP地址已经解析的主机端。
对于HTTP资源，连接复用还额外取决于是否拥有一个对于URL中的主机已经验证过的证书。该证书由服务器提供并且必须满足这种形式的检查，即在URL主机中形成一个新的TLS连接时客户端将执行任何检查。
源服务器可能提供一个拥有多个subjectAltName属性或者通配符的证书，其中之一是有效授权的URL。例如：一个带有*.example.com的subjectAltName证书将允许a.example.com和b.example.com使用同一个连接。
421（误导请求）状态码标识的是一个不能够产生响应的服务器请求。这个状态码可能会在服务器没有为产生经过计划和认证的响应进行相关的配置的时候产生。
客户端接收到服务器端发送的421(误导请求)响应可以通过不同的连接重试请求——不管这个请求方式是不是幂等的。这个连接可能是复用的（参见：Section 9.1.1），或者可选的服务被选择(参见 ALT-SVC)。
这个状态码绝对不能由代理端产生。
421的响应缓存是默认的。除非被定义的方法或者显式缓存控制另有说明
HTTP/2的实现必须使用TLS 1.2(参见： TLS12)或者更高的版本。通用的TLS指导（参见： TLSBCP）应该遵循，同时还需加上HTTP/2的一些额外限制条件。
TLS的实现必须支持服务器名称指示(SNI)的TLS扩展(参见：TLS-EXT)。HTTP/2客户端在协商TLS的时候必须注明目标域名。
HTTP/2的部署中在协商TLS1.3或者更高的版本时只需要支持和使用服务器域名指示（SNI）扩展。TLS1.2的部署需要遵循下面章节的要求。在实现过程中鼓励提供符合要求的默认值，部署的最终负责合规性。
本节描述了HTTP/2使用的TLS 1.2功能集限制。由于部署的限制，当一些限制没有遇到的时候TLS可能无法断开协商。终端必须立即终止一个不符合TLS要求的HTTP/2连接，并且把他们当做INADEQUATE_SECURITY处理（参见： Section5.4.1）。
通过TLS 1.2进行的HTTP/2部署必须禁止压缩。TLS的压缩可能导致信息的暴露（参见：RFC3749）。通用的压缩是不必要的，因为HTTP/2提供的压缩功能能够更好的联系上下文，因此可能更加的符合性能要求，安全或者其他方面。
通过TLS 1.2进行的HTTP/2部署必须禁止重新协商。终端必须将TLS协商定义为连接错误，类型为PROROCOL_ERROR（参见 Section 5.4.1）。务必注意由于密码套件可以加密消息的次数限制，禁止重新协商可能会导致长期连接编程不可用。
终端可以使用协商来对客户端握手提供机密性的保护，但是任何协商必须在发送连接前言之前。在建立连接后，服务器如果看到一个协商请求后会马上协商请求客户端证书。
这有效的防止了使用协商相应来请求一个特定的受保护资源。未来的规范可能会提供一种方式来支持这种需求。可替代地，服务器可以使用类型为HTTP_1_1_REQUIRED的错误（参见： Section 5.4）来请求客户端使用支持重新协商的协议。
实现必须在最少支持2048位短暂密码套件（DHE）——使用短暂的迪菲－赫尔曼密钥交换(参见：TLS12)和244位的密码套件（ecdhe）——使用短暂的椭圆曲线迪菲－赫尔曼密钥交换（参见：RFC4492）中等支持密钥交换的加密套件中使用。客户端必须接受高达4096的DHE尺寸。终端可以把小于密钥最小尺寸的协商看作为类型为INADEQUATE_SECURITY连接错误（参见 Section 5.4.1）
通过TLS 1.2进行的HTTP/2部署不应该使用任何流出在加密套件黑名单中的密码套件。
如果黑名单列表中的密码套件已经进行了协商，终端可以选择生成一个类型为INADEQUATE_SECURITY的连接错误。除非对等端接收这个密码套件，否则部署中选择使用黑名单中的密码套件会触发连接错误。
黑名单包括密码套件，TLS 1.2是强制性的，这就意外着TLS 1.2的部署可能使用密码套件的非相交集。为了避免这个问题使得TLS的握手失败，通过TLS 1.2部署的HTTP/2必须支TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(参见：TLS-ECDHE)与P-256椭圆曲线(参见： FIPS186)。
需要注意的是为了允许连接不支持HTTP/2的服务器，客户端上可能宣传支持黑名单上的密码套件。
这是的服务器用HTTP/2黑名单上的密码套件使用HTTP/1.1。然而，如果应用协议和加密套件是独立选择的，这可能会导致HTTP/2与黑名单上的密码套件进行协商。