这是一个类似HTTP 2 SOCKET，可以突破某些防火墙只允许80端口通信的障碍.zip

This is a readme file for a licensed version of HTTPort SDK. It's included with DEMO version so that you see what's in full package. -------------------------------------------------------------------------------- Table of contents. ~~~~~~~~~~~~~~~~~~ 1. SDK components overview. 2. HTTHost configuration. 3. Monitor configuration. 4. Client configuration. 5. Copyright information. -------------------------------------------------------------------------------- 1. SDK components overview. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ This SDK includes the following components: a) HTTHost - generic TCP/IP through HTTP tunneling server. Accepts HTTP requests from the clients, in case of SDK - applications using httport.dll, and translates the requests into local TCP/IP actions. Multiple instances of HTTHost can run on a single PC provided that their listening ports do not conflict. Multiple HTTHosts can be used by a single client, provided that the client knows the locations of all the hosts it wishes to use. This SDK includes both GUI and console versions of HTTHost. Console version may be run as service using srvany or similar program. b) Block.dll and grant.dll - security filters for HTTHost. Used for fine tuning tunneling restrictions with HTTHost. c) HTTCentral - HTTHost monitor. Allows remote monitoring of HTTHosts. d) HTTPort.dll - application level dynamic link library for interfacing with HTTHost. e) Source code for the library. Includes implementation of the interface unit only. Interface header files for C and Delphi. f) Test application in C which demonstrates the principles of the DLL usage. Compiled executable for this application. g) Registry tweaking file you are suggested to import into registry on the HTTHost servers. Optimizes TCP/IP settings for the needs of HTTHost. -------------------------------------------------------------------------------- 2. HTTHost configuration. ~~~~~~~~~~~~~~~~~~~~~~~~~ HTTHost is a single Win32 executable file. No libraries, or components are required to run it. Minimum system requirements include Windows NT/2000 with TCP/IP installed. The hardware configuration depends in fact on the number of clients that are using it. The simplest way to calculate the memory requirements is to multiply the number of simultaneous users by 64K. This is a very rough estimation, but it gives you the idea. That is for 1000 _simultaneous_ users you need about 64M physical memory for HTTHost itself. Nevertheless, that number of users requires really fast CPU, which is probably dual Pentium III something or similar. -------------------------- HTTHost reads its configuration upon start from the htthost.ini file, which must reside in the same directory. This file includes the following parameters: NOTE: All of the options can be configured at runtime from the Options tab, and this is the preferred way to configure HTTHost. Changes take place when you click Apply button. -------------------------- BindIP=X.X.X.X Interface: Options -> Bind to IP Binds HTTHost to accept incoming HTTP requests on specified IP/interface address only. 0.0.0.0 here means binding to all available interfaces. Dotted IP (0 <= X <= 255). -------------------------- ListenPort=X Interface: Options -> Bind to IP -> Port Sets HTTHost to listen the specified port on the above interface. Port number (0 <= X <= 65535). -------------------------- CentralIP=X.X.X.X Interface: Options -> Central IP The IP address to accept monitoring requests from. HTTHost will not allow to monitor its state using HTTCentral, if the request originates from IP different than that. 0.0.0.0 here means - allow monitoring for everybody. Dotted IP (0 <= X <= 255). -------------------------- PortShared=1 OR 0 Interface: Options -> Passthrough Allow or disallow passthrough cloaking feature of HTTHost (AKA port sharing). If enabled, HTTHost will pass all the requests it cannot recognize to the specified address, which is presumable some other HTTP server. This means that if anyone decides to surf (point one's browser) to the host where HTTHost resides, he or she will get the exact copy of the shared site. This setting is recommended to be turned on, yet it does not interfere HTTHost tunneling performance. 1 or 0. -------------------------- SharedAddress=host.name.com OR X.X.X.X Interface: Options -> Passthrough -> Host name or IP Host name (resolvable from HTTHost's point) or dotted IP of the HTTP server to pass the requests through if passthrough is enabled. In case it's set to nothing (or, to unresolvable name), HTTHost will automatically set this to 127.0.0.1. Host domain name or dotted IP (0 <= X <= 255). -------------------------- SharedPort=X Interface: Options -> Passthrough -> Port HTTP server port to pass the requests to if passthrough is enabled. Port number (0 <= X <= 65535). -------------------------- HeaderField=Some_string Interface: Options -> Passthrough -> Original IP header field Specifies the additional HTTP header field that HTTHost will append to the request it passes through. This allows the remote site to perform appropriate logging, if it's aware of HTTHost, of course. Otherwise, all connections are seen by the remote HTTP server as incoming from HTTHost machine with no indication where the request really came from. This field can be empty, in which case the request header field will be omitted. Character string. Recommended that you set it to X-Whatever, as proposed in RFCs. -------------------------- Passthrough example: If HTTHost is set to pass requests through to www.somesite.com on port 80 with header field of X-Original-IP, and it receives the following request from 207.251.25.63: GET robots.txt HTTP/1.0 Host: htthost.server.com The request that will actually be passed to the somesite HTTP server is: GET robots.txt HTTP/1.0 Host: www.somesite.com X-Original-IP: 207.251.25.63 End of Example. -------------------------- MaxLocalStorageBuffer=0..7 Interface: Options -> Max. local buffer This is actually an index in the drop down list. The option itself specifies the maximium amount of data to be buffered locally for a single connection. Example - the client has requested tunneling for some external HTTP proxy. The client has sent a request to GET a huge file. The proxy is transferring data to HTTHost. HTTHost will not receive more than that amount of data before the client fetches its data thus freeing some HTTHost memory. That is - proxy to HTTHost data transfer is delayed until the client receives the data which is already receieved by HTTHost. There is no suggested value for that parameter. 0 to 7. -------------------------- Timeouts=0..4 Interface: Options -> Timeouts This is actually an index in the drop down list.The option itself is three comma-separated timeout values in seconds. The description below is simplified a little, so that it's easier to understand. This is how it works - HTTPort communicates with HTTHost by means of series of GET requests, issuing a proper timeout before every request. The decision on how long the client has to wait before sending next request is made by server. Depending on the tunneled connection state HTTHost instructs it's clients to wait one of these three timeouts. If the tunneled connection is active, the first timeout is set, if it's idle for a little time, second, and if it's idle for a long time, third. This makes possible to put the idle connections to "lower priority", so that they do not load the server. From HTTHost admin's point of view, this setting is the tradeoff between client speed and server load. If the server is loaded very heavy, you can either install another one and share the load, or increase this timeout on the active