Changes between Version 63 and Version 64 of doc/meek


Ignore:
Timestamp:
Jun 5, 2014, 6:53:19 AM (5 years ago)
Author:
dcf
Comment:

Break out a "web services" section.

Legend:

Unmodified
Added
Removed
Modified
  • doc/meek

    v63 v64  
    4141See [[AChildsGardenOfPluggableTransports#meek|A Child's Garden of Pluggable Transports]] for details of how the protocol looks at the byte level, both at the TLS layer (the part visible to a censor), and at the HTTP layer (the invisible layer that carries the data).
    4242
    43 == General notes about App Engine ==
    44 
    45 Quotas for unpaid apps:
     43== Web services ==
     44
     45Google App Engine is just one example of a web service that may potentially be used by meek. Here are some web services that support domain fronting.
     46
     47=== Google App Engine ===
     48
     49{{{
     50$ wget -O - -q https://www.google.com/ --header 'Host: meek-reflect.appspot.com'
     51I’m just a happy little web server.
     52}}}
     53
     54[https://developers.google.com/appengine/ Google App Engine] is web application hosting on Google's infrastructure. This is the one that has been deployed so far. The front domain can be any Google domain, as far as I can tell, from www.google.com to www.youtube.com to www.orkut.com.
     55
     56There are quotas for unpaid apps:
    4657 * https://developers.google.com/appengine/docs/quotas
    4758You can pay to get higher quotas:
    4859 * https://developers.google.com/appengine/docs/pricing
    49 There is also a higher "premier" level of service that comes with support:
    50  * https://developers.google.com/appengine/docs/premier/
    51 Paying for more bandwidth on a public proxy server would be nice in that users wouldn't have to set up their own instance, and we could hardcode the server inside a browser bundle. (It would be nice to know the cost per gigabyte of running App Engine and, say, an ordinary Tor relay.)
    52 
    53 An idea to reduce overhead and eliminate polling is to use HTTP as a long-lived bidirectional channel, sending upstream data in a POST body and receiving data in the response body simultaneously. (That is, you send a POST with no Content-Length, the server reads your header and forwards the request to the relay, the server writes back a header, and after that you use the connection as an ordinary socket, with upstream and downstream data interleaved.) An implementation of this idea is at !https://www.bamsoftware.com/git/meeker.git. The idea doesn't work with App Engine, for two reasons. 1) [https://developers.google.com/appengine/docs/go/#Go_The_request_timer requests must be handled within 60 seconds], and 2) [https://developers.google.com/appengine/docs/go/#Go_Responses App Engine doesn't support streaming requests] of this kind:
    54  "App Engine calls the handler with a Request and a !ResponseWriter, then waits for the handler to write to the !ResponseWriter and return. When the handler returns, the data in the !ResponseWriter's internal buffer is sent to the user.
    55  This is practically the same as when writing normal Go programs that use the http package. The one notable difference is that App Engine does not support streaming data in response to a single request."
    56 App Engine doesn't even call your web app code until it has consumed the entire request body, and doesn't start flushing the response body until you close the output stream.
     60The cost is $0.12 per gigabyte, with 1 gigabyte free each day. There are other potential ancillary costs, having to do with things like how often your app is reloaded.
    5761
    5862== Using nginx instead of Google App Engine/PHP/etc ==
     
    131135== Ideas ==
    132136
    133 Instead of sending TLS with a front SNI, think about sending TLS with no SNI at all. (It might look like a really old browser or a non-browser daemon or something.) Then the censor doesn't have an SNI to match on, and has the choice of blocking an entire IP address (which may virtually host many domains) instead of a single SNI. This idea could be useful in deployment with a CDN, which though it may have thousands of domains, is blockable if we choose just one of those domains as a front.
     137An idea to reduce overhead and eliminate polling is to use HTTP as a long-lived bidirectional channel, sending upstream data in a POST body and receiving data in the response body simultaneously. (That is, you send a POST with no Content-Length, the server reads your header and forwards the request to the relay, the server writes back a header, and after that you use the connection as an ordinary socket, with upstream and downstream data interleaved.) An implementation of this idea is at !https://www.bamsoftware.com/git/meeker.git. The idea doesn't work with App Engine, for two reasons. 1) [https://developers.google.com/appengine/docs/go/#Go_The_request_timer requests must be handled within 60 seconds], and 2) [https://developers.google.com/appengine/docs/go/#Go_Responses App Engine doesn't support streaming requests] of this kind:
     138 "App Engine calls the handler with a Request and a !ResponseWriter, then waits for the handler to write to the !ResponseWriter and return. When the handler returns, the data in the !ResponseWriter's internal buffer is sent to the user.
     139 This is practically the same as when writing normal Go programs that use the http package. The one notable difference is that App Engine does not support streaming data in response to a single request."
     140App Engine doesn't even call your web app code until it has consumed the entire request body, and doesn't start flushing the response body until you close the output stream.
     141
     142Instead of sending TLS with a front SNI, think about sending TLS with no SNI at all. (It might look like a really old browser or a non-browser daemon or something.) Then the censor doesn't have an SNI to match on, and has the choice of blocking an entire IP address (which may virtually host many domains) instead of a single SNI. This idea could be useful in deployment with a CDN, which though it may have thousands of domains, is blockable if we choose just one of those domains as a front. See #12208.
    134143
    135144The App Engine [https://developers.google.com/appengine/docs/go/channel/ Channel API] provides a way to have long-lived push connections to the client, subject to a restricted interface. (HTTP handlers are otherwise [https://developers.google.com/appengine/docs/go/#Go_The_request_timer required to finish within 60 seconds].) The client could use HTTP request bodies to send data, and a channel to receive, and remove the need for polling. It would require us to reimplement the [https://developers.google.com/appengine/docs/go/channel/javascript client JavaScript channel API] in order to make use of the particular [https://en.wikipedia.org/wiki/Comet_%28programming%29 Comet]-based protocol.