[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] bandwidth overhead for gopher



On Thu, Jan 22, 2015 at 6:19 AM, barana . <barana24@hotmail.com> wrote:
>      Could someone please correct me.....
>  I am under the impression that gopher has a far smaller data use overhead
> for its transmission duties.. Could someone please confirm or deny?

The other respondents already touched the size difference between HTTP
and Gopher.  Still on this subject if you want to see a "real" HTTP
request in action, use Firefox (or your favourite browser), go to
`Developers` menu and then to the `Network` pane and activate it, and
then enter an URL like `google.com`.  Take the first request and look
at the request and response sizes, which are ~0.5KiB and ~1.2 KiB
(without any content).  This amount of data is what your browser
usually sends and receives for each request in addition to the actual
payload.  But as the others observed usually this size pales in
comparison with the actual content.

Also when comparing network efficiency, one is perhaps better to look
at the number of exchanged packets, which in both cases for extremely
small requests / replies can be only 1 in each direction, meaning that
in practical terms they are both as efficient.


However another easily overlooked advantage of HTTP is the possibility
to cache content by using the various cache control headers, something
which Gopher completely lacks (unless the client implements "covertly"
and thus breaking somewhat the experience).  Therefore if I access a
static site served with any "proper" HTTP server (say Nginx, LigHTTPD,
Apache, etc.) usually the content will be downloaded once, and no
mater how many times I switch back-and-forth between pages, I'll use
no extra bandwidth because the responses are cached.

Compare this with Gopher which doesn't have any caching control
mechanism, thus if I go between two menus (or files) back-and-forth,
although their content didn't changed, they will get downloaded again
and again.

Therefore if we take into account the HTTP caching ability, Gopher
loses quite badly.


But on the bright side, I currently can see Gopher used perhaps in
embedded software as a way to implement control dashboards or obtain
debugging data.  This is due to the protocols simplicity, where there
is no need for a Gopher client or server library, and one can use a
straight socket and be fully up-and-running, thus perhaps implement
something resembling a CGI solution in ten lines of Bash.

Ciprian.

_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project




Reply to: