mirror of
https://github.com/ScuroNeko/mtg.git
synced 2026-08-31 13:04:02 +03:00
Formatting of the README
This commit is contained in:
@@ -40,30 +40,30 @@ that probably matter.
|
|||||||
|
|
||||||
* **Domain fronting**
|
* **Domain fronting**
|
||||||
|
|
||||||
For years mtg supports domain fronting. This technique means that it fallbacks
|
For years mtg supports domain fronting. This technique means that it fallbacks
|
||||||
to accessing a real website in case if request fails. It could fail by many
|
to accessing a real website in case if request fails. It could fail by many
|
||||||
reasons: anti-replay protection, accidental access to the webserver or
|
reasons: anti-replay protection, accidental access to the webserver or
|
||||||
stale request. Anyway, if mtg rejects this request, it does not break a
|
stale request. Anyway, if mtg rejects this request, it does not break a
|
||||||
connection. It connects to the websites and replicates everything that client
|
connection. It connects to the websites and replicates everything that client
|
||||||
has sent, and simply proxies it back as is. Users will see a response from
|
has sent, and simply proxies it back as is. Users will see a response from
|
||||||
the real website, _byte-to-byte identical_ to the response of the real netloc.
|
the real website, _byte-to-byte identical_ to the response of the real netloc.
|
||||||
|
|
||||||
* **Doppelganger**
|
* **Doppelganger**
|
||||||
|
|
||||||
mtg also is a doppelganger of the website it fronts. Sure, with domain fronting
|
mtg also is a doppelganger of the website it fronts. Sure, with domain fronting
|
||||||
users will see replies of the real website in case if something will go wrong.
|
users will see replies of the real website in case if something will go wrong.
|
||||||
But what about such cases when _everything is fine_?
|
But what about such cases when _everything is fine_?
|
||||||
|
|
||||||
In that case mtg mimics TLS connection statistical characteristics as close as
|
In that case mtg mimics TLS connection statistical characteristics as close as
|
||||||
possible. Different application have different statistics of their patterns.
|
possible. Different application have different statistics of their patterns.
|
||||||
Big CDN steadily pumping the data, small websites burst with short easily
|
Big CDN steadily pumping the data, small websites burst with short easily
|
||||||
compressiable chunks of traffic.
|
compressiable chunks of traffic.
|
||||||
|
|
||||||
mtg artificially emulates those delays to be statistically indistinguishable
|
mtg artificially emulates those delays to be statistically indistinguishable
|
||||||
from the real website even if it covers connection of the very specific app.
|
from the real website even if it covers connection of the very specific app.
|
||||||
It also follows 2 most common patterns of traffic chunking, so censors
|
It also follows 2 most common patterns of traffic chunking, so censors
|
||||||
will have to put more resources to find out that we have Telegram here
|
will have to put more resources to find out that we have Telegram here
|
||||||
but not a hookah webshop served by nginx.
|
but not a hookah webshop served by nginx.
|
||||||
|
|
||||||
* **Resource-efficient**
|
* **Resource-efficient**
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user