一.WEB开发概述
1>.C/S编程
CS即客户端、服务器编程。
客户端、服务端之间需要使用Socket，约定协议、版本(往往使用的协议是TCP或者UDP)，指定地址和端口，就可以通信了。
客户端、服务端传输数据，数据可以有一定的格式，双方必须先约定好。
2>.B/S编程
BS编程，即Browser、Server开发。
Browser浏览器，一种特殊的客户端，支持HTTP(s)等协议，能够通过URL向服务端发起请求，等待服务端返回HTML等数据，并在浏览器内可视化展示的程序。
Server，支持HTTP(s)协议，能够接受众多客户端发起的HTTP协议请求，经过处理，将HTML等数据返回给浏览器。
本质上来说，BS是一种特殊的CS，即客户端必须是一种支持HTTP协议且能解析并渲染HTML的软件， 服务端必须是能够接收多客户端HTTP访问的服务器软件。
HTTP协议底层基于TCP协议实现。
BS开发分为两端开发（前后端分离）：
客户端开发，或称前端开发。HTML、CSS、JavaScript等
服务端开发，Python有WSGI、Django、Flask、Tornado等
二.HTTP协议概述
1>.http协议和版本介绍
基于TCP:
http/0.9
1991，原型版本，功能简陋，只有一个命令GET。GET /index.html ,服务器只能回应HTML格式字符串，不能回应别的格式
http/1.0
1996年5月,支持cache, MIME, method
每个TCP连接只能发送一个请求，发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接
引入了POST命令和HEAD命令
头信息是ASCII码，后面数据可为任何格式。服务器回应时会告诉客户端，数据是什么格式，即Content-Type字段的作用。这些数据类型总称为MIME多用途互联网邮件扩展，每个值包括一级类型和二级类型，预定义的类型，也可自定义类型, 常见Content-Type值:"text/xml","image/jpeg","audio/mp3"。
http/1.1
1997年1月发布。
引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。对于同一个域名，大多数浏览器允许同时建立6个持久连接
引入了管道机制（pipelining），即在同一个TCP连接里，客户端可以同时发送多个请求，进一步改进了HTTP协议的效率
新增方法：PUT、PATCH、OPTIONS、DELETE
同一个TCP连接里，所有的数据通信是按次序进行的。服务器只能顺序处理回应，前面的回应慢，会有许多请求排队，造成"队头堵塞"（Head-of-line blocking）
为避免上述问题，两种方法：一是减少请求数，二是同时多开持久连接。网页优化技巧，如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等
HTTP 协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度
Spdy
2009年,谷歌研发,解决 HTTP/1.1 效率不高问题。
http/2.0
2015年发布。
头信息和数据体都是二进制，称为头信息帧和数据帧
复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了"队头堵塞",此双向的实时通信称为多工（Multiplexing）
引入头信息压缩机制（header compression）,头信息使用gzip或compress压缩后再发送；客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，不发送同样字段，只发送索引号，提高速度
HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送（server push）
基于UDP:
http/3.0
博主推荐阅读:https://zhuanlan.zhihu.com/p/32553477
据W3Techs统计，截止到2019年12月2日，HTTP / 3被所有网站的2％和前1000个网站的7％使用。如下图所示，从趋势上来看离咱们的生产环境使用还很远。链接地址:https://w3techs.com/technologies/overview/site_element
2>.http协议的无状态，有连接和短连接
无状态:
指的是服务器无法知道2次请求之间的联系，即使是前后2次同一个浏览器也没有任何数据能够判断出是同一个浏览器的请求。后来可以通过cookie(客户端存放)、session(服务端存放)来判断。
有连接:
是因为它基于TCP协议，是面向连接的，需要3次握手、4次断开。
短连接:
Http 1.1之前，都是一个请求一个连接，而Tcp的连接创建销毁成本高，对服务器有很大的影 响。所以，自Http 1.1开始，支持keep-alive，默认也开启，一个连接打开后，会保持一段时间(可设 置)，浏览器再访问该服务器就使用这个Tcp连接，减轻了服务器压力，提高了效率。
3>.URI(Uniform Resource Identifier) 统一资源标识，分为URL和URN
URN(Uniform Resource Naming，统一资源命名)
示例：
douluodalu:?xt=urn:btih:660557A6890EF888666(P2P下载使用的磁力链接是URN的一种实现，如迅雷下载)
URL(Uniform Resorce Locator，统一资源定位符，用于描述某服务器某特定资源位置)
格式:
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
相关参数解释:
scheme:
方案，模式，协议，说白了就是访问服务器以获取资源时要使用哪种协议,如:http,ftp,https,file,mailto,rtsp等等。
示例:
rtsp://videoserver/video_demo/
rtsp:Real Time Streaming Protocol。该协议是流媒体协议，多用于视频播放，感兴趣的小伙伴可以自己搭建一个流媒体服务器来做一个家庭影院。
user:
用户，某些方案访问资源时需要的用户名
password:
密码，用户对应的密码，中间用：分隔
host:
主机，资源宿主服务器的主机名或IP地址
port:
端口,资源宿主服务器正在监听的端口号，很多方案有默认端口号
path:
路径,服务器资源的本地名，由一个/将其与前面的URL组件分隔
params:
参数，指定输入的参数，参数为名/值对，多个参数，用;分隔
query:
查询，传递参数给程序，如数据库，用？分隔,多个查询用&分隔
frag:
片段,一小片或一部分资源的名字，此组件在客户端使用，用#分隔 URL示例: http://apache.org/index.html#projects-list
两者区别：
URN如同一个人的名称，而URL代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。URN仅用于命名，而不指定地址
4>.http事物
http事务：
一次访问的过程，分为Request、Response。
请求(request):
浏览器向服务器发起的请求
响应(response) :
服务器对客户端请求的响应
需要注意的是:
请求报文由Header消息报头、Body消息正文组成(可选)，请求报文第一行称为请求行
响应报文由Header消息报头、Body消息正文组成(可选)，响应报头第一行称为状态行
每一行使用回车和换行符作为结尾
如果有Body部分，Header、Body之间留一行空行用以区分两者消息
5>.http常用的方法(method)
GET：
从服务器获取一个资源
HEAD：
只从服务器获取文档的响应首部
POST：
向服务器输入数据，通常会再由网关程序继续处理
PUT：
将请求的主体部分存储在服务器中，如上传文件
DELETE：
请求删除服务器上指定的文档
TRACE：
追踪请求到达服务器中间经过的代理服务器
OPTIONS：
请求服务器返回对指定资源支持使用的请求方法
扩展方法：
LOCK，MKCOL，COPY，MOVE等；
6>.协议查看或分析的工具
tcpdump, wireshark,tshark
三.HTTP请求报文
请求报文语法格式如下所示:(和下图相对应)
<method> <request-URL> <version>
<headers>
<entity-body>
以上参数说明:
method:
请求方法，标明客户端希望服务器对资源执行的动作GET、HEAD、POST等
request-URL:
请求的PATH路径
version:
HTTP协议的版本号，HTTP/<major>.<minor>，如"HTTP/1.1"
headers:
每个请求或响应报文可包含任意个首部；每个首部都有首部名称，后面跟一个冒号，而后跟一个可选空格，接着是一个值。
entity-body:
请求时附加的数据,通常GET方法不用实体主体，一般使用POST方法时可能会用到该部分来向服务端提交参数。
四.HTTP响应报文
响应报文如下所示:(和下图相对应)
<version> <status> <reason-phrase>
<headers>
<entity-body>
以上参数说明:
version:
HTTP协议的版本号，HTTP/<major>.<minor>，如"HTTP/1.1"。
status:
通常是三位数字，如200，301, 302, 404, 502; 标记请求处理过程中发生的情况。
headers:
每个请求或响应报文可包含任意个首部；每个首部都有首部名称，后面跟一个冒号，而后跟一个可选空格，接着是一个值。
reason-phrase：
原因短语，即状态码所标记的状态的简要描述
entity-body:
响应时附加的数据,比如响应一个页面内容。
五.HTTP 首部信息
1>.HTTP协议首部(headers)字段
HTTP首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。使用首部字段是为了给客服端和服务器端提供报文主体大小、所使用的语言、认证信息等内容
首部字段结构HTTP首部字段是由首部字段名和字段值构成的，中间用冒号(":")分隔
字段值对应单个HTTP首部字段可以有多个值
报文首部中出现了两个或以上具有相同首部字段名的首部字段时，在规范内尚未明确，根据浏览器内部处理逻辑的不同，优先处理的顺序可能不同，结果可能并不一致
2>. HTTP协议首部(headers)的分类
通用首部:
请求报文和响应报文两方都会使用的首部。
常见的通用首部如下所示:
Date:
报文的创建时间
Connection:
连接状态，如keep-alive, close
Via:
显示报文经过的中间节点（代理，网关）
Cache-Control:
控制缓存，如缓存时长
MIME-Version:
发送端使用的MIME版本
Warning:
错误通知
请求首部:
从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、请求内容相关优先级等信息。
常用的客户端专用请求首部如下所示:
Client-IP:
请求的客户端IP
Host:
请求的服务器名称和端口号
Referer:
跳转至当前URI的前一个URL
User-Agent:
客户端代理，浏览器版本
Accept请求首部:
用户标明客户自己更倾向于支持使用的方式。
常用的Accept首部如下所示:
Accept：
指明服务器能发送的媒体类型
Accept-Charset:
支持使用的字符集
Accept-Encoding:
支持使用的编码方式
Accept-Langage:
支持使用语言
条件式请求首部：
主要应用于缓存机制的判断。
常见的条件试请求首部如下所示:
Expect:
允许客户端列出某请求所要求的服务器行为
If-Modified-Since:
自从指定的时间之后，请求的资源是否发生过修改
If-Unmodified-Since:
与上面相反
If-None-Match:
本地缓存中存储的文档的ETag标签是否与服务器文档的Etag不匹配
If-Match:
与上面相反
安全请求首部：
跟安全相关的请求首部。
常见的安全请求首部如下所示:
Authorization:
向服务器发送认证信息，如账号和密码
Cookie:
客户端向服务器发送cookie
cookie2:
cookie的另外一个版本。
代理请求首部：
Proxy-Authorization:
向代理服务器认证
响应首部：
从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
常见的信息性响应首部如下所示:
Age:
从最初创建开始，响应持续时长
Server:
服务器程序软件名称和版本
协商响应首部:
某资源有多种表示方法时使用。
常见的协商响应首部如下所示:
Accept-Ranges:
对当前资源来讲，服务器可接受的请求范围类型(比如服务器是否支持压缩和不压缩，有的服务器不支持压缩文件)
Vary:
服务器查看的其它首部列表，服务端会根据列表中对内容挑选出最合适对版本发送给客户端。
安全响应首部：
跟安全相关对响应首部。
常见对安全响应首部如下所示:
Set-Cookie:
服务端在某个客户端第一次请求时发送令牌，即向客户端设置cookie。
Set-Cookie2:
Set-Cookie的另外一个版本。
WWW-Authenticate:
来自服务器对客户端的质询列表，即要求客户提供账号和密码。
实体首部：
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的的信息。
常见的实体首部如下所示:
Allow:
列出对此资源实体可使用的请求方法
Location:
告诉客户端真正的实体位于何处，即资源新为止，我们在对网站做重定向对时候就会有该属性哟。
内容首部:
用于标明内容格式或内容类型等等。
常见的内容首部如下所示:
Content-Encoding:
对主体执行的编码
Content-Language:
理解主体时最适合的语言
Content-Length:
主体的长度
Content-Location:
实体真正所处位置
Content-Type：
主体的对象类型，如最常见的"text/html"。
缓存首部:
和缓存相关的首部。
常见的缓存首部如下所示:
ETag:
实体的扩展标签
Expires:
实体的过期时间
Last-Modified:
最后一次修改的时间
扩展首部:
即非标准首部，可能是有程序开发者创建的，例如X-Forward-For。
六.HTTP协议状态码(status code)分类
1>.状态码分类
状态码在响应头第一行,状态码被分为五类,如下所示:
1xx:
提示信息，用于表示临时响应并需要请求者执行操作才能继续的状态代码，如"100-101"。
2xx：
表示响应成功，如"200-206"。
3xx：
表示重定向，如"300=307"。
4xx:
客户端请求错误，如"400-417"。
5xx：
服务器端错误,如"500-505"。
2>.常见的状态码
100(继续):
请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。
101(切换协议)
请求者已要求服务器切换协议，服务器已确认并准备进行切换。
200 OK
成功，请求数据通过响应报文的entity-body部分发送，即正常返回了网页内容
201 Created
请求已经被实现，依据请求要求，已经创建了新的资源
204 No Content
服务器端成功处理了，但没什么内容返回
301 Moved Permanently
请求的URL指向的资源已经被删除；但在响应报文中通过首部Location指明了资源现在所处的新位置。即页面永久性移走，永久重定向。返回新的URL，浏览器会根据返回的url发起新的request请求
302 Temporary Redirect
响应报文Location指明资源临时新位置,即临时重定向
304 Not Modified
客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应状态码通知客户端。即资源未修改，浏览器使用本地缓存
307 Temporary Redirect
与302很相似，只是客户端保持当前请求方法不变重定向
400 Bad Request
请求语法错误
401 Unauthorized
请求要求身份验证，如需要输入账号和密码认证方能访问资源。
403 Forbidden
服务器拒绝请求 ，即请求被禁止。
404 Not Found
服务器无法找到客户端请求的资源，即网页找不到，客户端请求的资源有错
500 Internal Server Error
服务器内部错误，如配置文件中定义规则错误(并非配置文件语法错误)。
502 Bad Gateway
代理服务器从后端服务器收到了一条伪响应，如无法连接到网关。即上游服务器错误，例如nginx反向代理的时候。
503 Service Unavailable
服务不可用，临时服务器维护或过载，服务器无法处理请求
504 Gateway timeout
网关超时
博主推荐阅读:
https://baike.baidu.com/item/%E7%8A%B6%E6%80%81%E4%BB%A3%E7%A0%81/9910359?fromtitle=%E7%8A%B6%E6%80%81%E7%A0%81&fromid=16802080&fr=aladdin
七.Cookie
1>.什么是cookie
Cookie技术概述:
(1)键值对信息
(2)是一种客户端、服务器端传递数据的技术
(3)一般来说cookie信息是在服务器端生成，返回给浏览器端的
(4)浏览器端可以保持这些值，浏览器对同一域发起每一请求时，都会把Cookie信息发给服务器端
(5)服务端收到浏览器端发过来的Cookie，处理这些信息，可以用来判断这次请求是否和之前的请求有关联
曾经Cookie唯一在浏览器端存储数据的手段，目前浏览器端存储数据的方案很多，Cookie正在被淘汰。
当服务器收到HTTP请求时，服务器可以在响应头里面添加一个Set-Cookie键值对。浏览器收到响应后 通常会保存这些Cookie，之后对该服务器每一次请求中都通过Cookie请求头部将Cookie信息发送给服务器。
另外，Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。
2>.为啥要使用cookie
HTTP是一种无状态协议,使用cookie技术来保存浏览器与服务端的连接状态:
协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。可是随着Web的不断发展，很多业务都需要对通信状态进行保存。于是引入了cookie技术。
使用cookie的状态管理:
cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态。cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入cookie值后发送出去。服务器端发现客户端发送过来的cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
2>.Set-Cookie首部字段
Set-cookie首部字段示例：
Set-Cookie: status=enable; expires=Fri, 24 Nov 2017 20:30:02 GMT; path=/;
NAME=VALUE
赋予cookie的名称和其值,此为必需项
expires=DATE
设置cookie的有效期，即cookie可以设定过期终止时间，过期后将被浏览器清除。如果缺省，cookie不会持久化，随着浏览器关闭cookie消失，称为会话cookie。
path=PATH
将服务器上的文件目录作为cookie的适用对象，若不指定则默认为文档所在的文件目录,即确定哪些目录及子目录访问可以使用该cookie。
domain=域名
作为cookie适用对象的域名，若不指定则默认为创建cookie的服务器的域名。域确定有哪些域可以存取这个cookie，缺省设置属性值为当前主机，例如"www.yinzhengjie.org.cn"。如果设置为"yinzhengjie.org.cn"表示包含子域。
Secure
仅在HTTPS安全通信时才会发送cookie,表示cookie随着HTTPS加密过得请求发送给服务端,有些浏览器已经不允许http://协议使用secure了,这个secure不能保证Cookie是安全的，Cookie中不要传输铭感信息。
HttpOnly
加以限制使cookie不能被JavaScript脚本访问
3>.查看IE浏览器的cookie信息
4>.查看Google浏览器的cookie信息(chrome://settings/siteData)
5>.通过PHP程序自定义cookie信息案例
yum -y install httpd
Loaded plugins: fastestmirror
Determining fastest mirrors
* base: mirror.jdcloud.com
* extras: mirror.jdcloud.com
* updates: mirrors.aliyun.com
base | 3.6 kB 00:00:00
extras | 2.9 kB 00:00:00
updates | 2.9 kB 00:00:00
(1/4): base/7/x86_64/group_gz | 165 kB 00:00:00
(2/4): extras/7/x86_64/primary_db | 153 kB 00:00:00
(3/4): base/7/x86_64/primary_db | 6.0 MB 00:00:03
(4/4): updates/7/x86_64/primary_db | 5.8 MB 00:00:06
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-90.el7.centos will be installed
--> Processing Dependency: httpd-tools = 2.4.6-90.el7.centos for package: httpd-2.4.6-90.el7.centos.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-90.el7.centos.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-90.el7.centos.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-5.el7 will be installed
---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed
---> Package httpd-tools.x86_64 0:2.4.6-90.el7.centos will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================
Installing:
httpd x86_64 2.4.6-90.el7.centos base 2.7 M
Installing for dependencies:
apr x86_64 1.4.8-5.el7 base 103 k
apr-util x86_64 1.5.2-6.el7 base 92 k
httpd-tools x86_64 2.4.6-90.el7.centos base 91 k
Transaction Summary
=============================================================================================================================================
Install 1 Package (+3 Dependent packages)
Total download size: 3.0 M
Installed size: 9.9 M
Downloading packages:
(1/4): httpd-tools-2.4.6-90.el7.centos.x86_64.rpm | 91 kB 00:00:00
(2/4): apr-1.4.8-5.el7.x86_64.rpm | 103 kB 00:00:00
(3/4): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:00
httpd-2.4.6-90.el7.centos.x86_ FAILED ] 1.6 B/s | 668 kB 434:12:11 ETA
http://mirrors.nju.edu.cn/centos/7.7.1908/os/x86_64/Packages/httpd-2.4.6-90.el7.centos.x86_64.rpm: [Errno 12] Timeout on http://mirrors.nju.e
du.cn/centos/7.7.1908/os/x86_64/Packages/httpd-2.4.6-90.el7.centos.x86_64.rpm: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')Trying other mirror.
(4/4): httpd-2.4.6-90.el7.centos.x86_64.rpm | 2.7 MB 00:00:01
---------------------------------------------------------------------------------------------------------------------------------------------
Total 66 kB/s | 3.0 MB 00:00:46
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : apr-1.4.8-5.el7.x86_64 1/4
Installing : apr-util-1.5.2-6.el7.x86_64 2/4
Installing : httpd-tools-2.4.6-90.el7.centos.x86_64 3/4
Installing : httpd-2.4.6-90.el7.centos.x86_64 4/4
Verifying : apr-1.4.8-5.el7.x86_64 1/4
Verifying : httpd-tools-2.4.6-90.el7.centos.x86_64 2/4
Verifying : apr-util-1.5.2-6.el7.x86_64 3/4
Verifying : httpd-2.4.6-90.el7.centos.x86_64 4/4
Installed:
httpd.x86_64 0:2.4.6-90.el7.centos
Dependency Installed:
apr.x86_64 0:1.4.8-5.el7 apr-util.x86_64 0:1.5.2-6.el7 httpd-tools.x86_64 0:2.4.6-90.el7.centos
Complete!
[root@node107.yizhengjie.org.cn ~]#
[root@node107.yizhengjie.org.cn ~]# yum -y install httpd
[root@node107.yizhengjie.org.cn ~]# yum -y install php
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.jdcloud.com
* extras: mirror.jdcloud.com
* updates: mirrors.aliyun.com
base | 3.6 kB ::
extras | 2.9 kB ::
updates | 2.9 kB ::
Resolving Dependencies
--> Running transaction check
---> Package php.x86_64 :5.4.-46.1.el7_7 will be installed
--> Processing Dependency: php-common(x86-) = 5.4.-46.1.el7_7 for package: php-5.4.-46.1.el7_7.x86_64
--> Processing Dependency: php-cli(x86-) = 5.4.-46.1.el7_7 for package: php-5.4.-46.1.el7_7.x86_64
--> Running transaction check
---> Package php-cli.x86_64 :5.4.-46.1.el7_7 will be installed
---> Package php-common.x86_64 :5.4.-46.1.el7_7 will be installed
--> Processing Dependency: libzip.so.()(64bit) for package: php-common-5.4.-46.1.el7_7.x86_64
--> Running transaction check
---> Package libzip.x86_64 :0.10.-.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================
Installing:
php x86_64 5.4.-46.1.el7_7 updates 1.4 M
Installing for dependencies:
libzip x86_64 0.10.-.el7 base k
php-cli x86_64 5.4.-46.1.el7_7 updates 2.7 M
php-common x86_64 5.4.-46.1.el7_7 updates k
Transaction Summary
=============================================================================================================================================
Install Package (+ Dependent packages)
Total download size: 4.7 M
Installed size: M
Downloading packages:
(/): libzip-0.10.-.el7.x86_64.rpm | kB ::
(/): php-common-5.4.-46.1.el7_7.x86_64.rpm | kB ::
(/): php-cli-5.4.-46.1.el7_7.x86_64.rpm | 2.7 MB ::
(/): php-5.4.-46.1.el7_7.x86_64.rpm | 1.4 MB ::
---------------------------------------------------------------------------------------------------------------------------------------------
Total 6.0 MB/s | 4.7 MB ::
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : libzip-0.10.-.el7.x86_64 /
Installing : php-common-5.4.-46.1.el7_7.x86_64 /
Installing : php-cli-5.4.-46.1.el7_7.x86_64 /
Installing : php-5.4.-46.1.el7_7.x86_64 /
Verifying : php-common-5.4.-46.1.el7_7.x86_64 /
Verifying : php-cli-5.4.-46.1.el7_7.x86_64 /
Verifying : libzip-0.10.-.el7.x86_64 /
Verifying : php-5.4.-46.1.el7_7.x86_64 /
Installed:
php.x86_64 :5.4.-46.1.el7_7
Dependency Installed:
libzip.x86_64 :0.10.-.el7 php-cli.x86_64 :5.4.-46.1.el7_7 php-common.x86_64 :5.4.-46.1.el7_7
Complete!
[root@node107.yizhengjie.org.cn ~]#
[root@node107.yizhengjie.org.cn ~]# yum -y install php
[root@node107.yizhengjie.org.cn ~]# cat /var/www/html/phpinfo.php #编写php测试代码
<?php
phpinfo();
?>
[root@node107.yizhengjie.org.cn ~]#
[root@node107.yizhengjie.org.cn ~]# httpd -t
Syntax OK
[root@node107.yizhengjie.org.cn ~]#
[root@node107.yizhengjie.org.cn ~]# systemctl restart httpd #重启服务后若能看到如下图所示的界面说明PHP是安装成功的
[root@node107.yizhengjie.org.cn ~]#
[root@node107.yizhengjie.org.cn ~]# cat /var/www/html/setcookie.php #创建cookie信息，当我们在浏览器访问时可以看到我们定义的2个cookie信息，如下图所示。
<?php
setcookie('department','IT');
setcookie('user','Jason',time()+);
?>
[root@node107.yizhengjie.org.cn ~]#
如上图所示我们在访问浏览器时的确是可以看到两个cookie信息的，一个是department的cookie，它是临时性的cookie，当浏览器关闭后就自动消失啦。另一个是user的cookie，它也是一个时效性的cookie，我们在代码中定义了他的有效时间是3600秒，即1小时。
综上所述，我们关闭操作系统的所有浏览器后，department对应的cookie也会随之消失，而只有user对应的cookie会保存一小时，于是我们打开Google浏览器，验证这一结论，如下图所示，的确只能看到user对应的cookie啦。
6>.cookie的缺点
Cookie一般明文传输(Secure是加密传输)，安全性极差，不要传输敏感数据
有4kB大小限制
每次请求中都会发送Cookie，增加了流量。
八.session
WEB服务器端，尤其是动态网页服务端Server，有时需要知道浏览器方是谁?但是HTTP是无状态的，怎么办?
服务端会为每一次浏览器端第一次访问生成一个SessionID，用来唯一标识该浏览器，通过Set-Cookie发送到浏览器端。
浏览器端收到之后并不永久保持这个Cookie，只是会话级的。浏览器访问服务端时，会使用Cookie，也会带上这个SessionID的Cookie值。
服务端会维持这个SessionID一段时间，如果超时，会清理这些超时没有人访问的SessionID。如果浏览器端发来的SessionID无法在服务端找到，就会自动再次分配新的SessionID，并通过Set-Cookie发送到浏览器端以覆盖原有的存在浏览器中的会话级的SessionID。
推荐图书《HTTP权威指南》
630
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
