HTTP代理是基于TCP的socket连接，就是A无法直接连接C，但B即可以连接A，也可以连接B
那么需要B开启他的代理服务，设置服务器并监听端口。
A连接B的80或者8080代理服务器端口，建立socketAB，发送（连接C的WEB请求）到B，B收到该请求后进行解析，然后B去连接C，建立socketBC,并通过socketBC把（连接C的WEB请求）发送给C。

反之依然。

也就是说TCP层知道是A->B->C，但是HTTP封装的包只知道是A->C

HTTP代理是基于TCP的socket连接，就是A无法直接连接C，但B即可以连接A，也可以连接B
那么需要B开启他的代理服务，设置服务器并监听端口。
A连接B的80或者8080代理服务器端口，建立socketAB，发送（连接C的WEB请求）到B，B收到该请求后进行解析，然后B去连接C，建立socketBC,并通过socketBC把（连接C的WEB请求）发送给C。

反之依然。

也就是说TCP层知道是A->B->C，但是HTTP封装的包只知道是A->C

不是HTTP啊 是HTTPS啊

为了便于更好的认识和理解SSL 协议，这里着重介绍SSL 协议的握手协议。SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：
①客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
②服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通讯的加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

这是度娘百科里面的。。。 维基里面有更详细的。

可能是我的表达不好 其实我好奇的是Https代理服务器是如何转发数据的 不是SSL 协议啊，因为我也想实现下这个过程

那是你说的中间人了。 这个需要客户端对证书不做可信校验的时候才能运行。

请问https代理是否要跟客户端和远程服务器分别建立ssl连接然后开始传输数据

肯定要啊。

怎么老有回帖不仔细看问题的人.
百度知道,CSDN这种人最多.

可以参考goagent的源码

如果代理服务器没有用于https通信的服务器和客户端证书的话，是不能直接https代理的，除非使用ssl tunnel，但ssl tunnel是基于tcp的，没啥不同，唯一可能就是需要使用CONNECT方法进行认证。

可以借用goagent的证书

嗯 我看过了 不过感觉goagent应该不是真正意义上的https服务器，goagent能够看到通信内容 ，https代理应该是看不到的才对吧

如果是看不到https內容的話,就只是普通的transparent proxy或reverse proxy,
這類型的proxy基本上都不太會更動到像SSL這種presentation layer的東西,
只會改動到TCP與IP header的部分

其實我倒覺得你應該把問題描述得更詳細一點,現在實作支援https的proxy還不少,
方法論述與目的都不太相同,想用一個大方向問題拿到全部答案可能比較難有人可以回答的全

我找了份文档:
01http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling-01
普通HTTPs代理只是充当了转发的功能，比如服务器在收到CONNECT www.xxx.com:443 HTTP/1.0请求后返回   HTTP/1.0 200 Connection established通知客户端建立了连接，之后只负责把客户端的数据转发到相关端口。不过goagent那种是属于通过假证书再与两边连接的

你说的那种就不叫https代理了。如果只是纯转发。那他就是把所有的数据流量做为http的报文直接转发了。 根本就不处理https了。

要对https的内容做了处理的才能叫https代理。

通过连接，客户端写一个ASCII文本请求行，后跟0或多个HTTP头标，一个空行和实现请求的任意数据。
一个请求由四个部分组成：请求行、请求头标、空行和请求数据
1.请求行：请求行由三个标记组成：请求方法、请求URI和HTTP版本，它们用空格分隔。
例如：GET /index.html HTTP/1.1
HTTP规范定义了8种可能的请求方法：
GET            检索URI中标识资源的一个简单请求
HEAD            与GET方法相同，服务器只返回状态行和头标，并不返回请求文档
POST            服务器接受被写入客户端输出流中的数据的请求
PUT            服务器保存请求数据作为指定URI新内容的请求
DELETE            服务器删除URI中命名的资源的请求
OPTIONS        关于服务器支持的请求方法信息的请求
TRACE            Web服务器反馈Http请求和其头标的请求
CONNECT        已文档化但当前未实现的一个方法，预留做隧道处理

goagent的https不是真正的ssl加密的，只是在本地浏览器中导入的证书欺骗浏览器的，，因为google ape根本就不支持ssl加密。。。

HTTPS的工作原理：HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3.获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

我大概明白LZ的意思，我之前遇到过一种情况：
内部网络的主机不能直接连接外网，只能通过HTTP Proxy，例如squid，访问外部网站，而且通常只允许访问80、443、8080这样的端口。当你通过HTTP代理访问外网服务时，如果你请求的是http协议的数据，代理会先接收你的请求，然后发送请求到服务器，获得响应后先在本地建立缓存，并将缓存返回给客户端。这个过程中，你发出的数据会被HTTP代理解析、修改。
但是如果你请求的是https协议的数据，由于https协议本身是加密的，只有在你的请求没有受到任何修改的情况下（HTTP头也不能被修改），客户端才能正确获得响应。因此，HTTP代理不会修改你的请求，只会在客户端和服务器之间建立一个HTTP的CONNECT连接，连接建立成功后，客户端可以将此连接当作普通的socks连接，用它传输任何内容，例如用作端口转发。
很多木马都会使用这种技术作内网穿透，效果也非常好。

我理解https代理，应该在客户端导入代理的证书。客户端请求https 的web网页时，握手方是代理，代理解密后，再用自己的证书和最终网站方握手。这样，浏览器看到的代理就是最终网站，最终网站看到的代理就是浏览器。
中间的关键问题就是证书。浏览器需要将代理的证书及颁发机构设为可信任。
goagent源码我没看，中间如何将http转为https，应该有点技巧。
像对于国家防火墙这样的大型防火墙和代理，如要方便解密，还是需要在浏览器安装证书。这里面会有些方法。如果只是随机中断连接，无法监听，则容易得多。在DNS解析，IP可达性，传输层上做文章即可。

学习了，谢谢分享！！！！！！！！！！！

原理我可能帮不到你，不过我本人有大量HTTPS代理~ 1小时更新一次 实时可用1.5W，一天大概20W左右

http://www.cnblogs.com/zhangdongsheng/p/3425931.html