The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
http клиент/сервер: порядок закрытия соединения, !*! devcoder, 09-Июн-09, 22:04  [смотреть все]
Привет.

Регулируется ли чем (rfc, например) порядок закрытия close(2)
транспортных соединений tcp протокола http
с целью снижения нагрузки на сетевой стек сервера (FIN_WAIT,CLOSE_WAIT,etc)?
Или может просто какие-то де-факто советы есть.

Например, последние данные переданы и приняты
и соединение должно быть закрыто.
В какой-то момент об этом одновременно знают и клиент и сервер.
Есть 3 варианта:
1) обе стороны асинхронно вызывают close(2);
2) клиент ждет read(2) закрытия соединения со стороны сервера
   и только после этого вызывает close();
3) сервер ждет закрытия соединения клиентом.

3-й вариант, конечно, кажется сомнительным,
привёл просто как один из возможных.
  

  • http клиент/сервер: порядок закрытия соединения, !*! svn, 22:39 , 09-Июн-09 (1)
    Если отправил всё что хотел, закрывай сокет на отправку (shutdown), читай остатки что присылает другая сторона и жди пока она закроет, или соединение оборвётся, или сам закрой спустя таймаут.

    Про http читай соотв RFC там есть keepalive, позволяющий не закрывать соединение между запросами.

    • http клиент/сервер: порядок закрытия соединения, !*! devcoder, 08:22 , 10-Июн-09 (2)
      >Если отправил всё что хотел, закрывай сокет на отправку (shutdown), читай остатки
      >что присылает другая сторона и жди пока она закроет, или соединение
      >оборвётся, или сам закрой спустя таймаут.

      Видимо предлагаете так клиентской стороне действовать.
      Это только ваши рекомендации или где-то читали?

  • http клиент/сервер: порядок закрытия соединения, !*! ALu, 11:07 , 11-Июн-09 (3)
    >Привет.
    >
    >Регулируется ли чем (rfc, например) порядок закрытия close(2)
    >транспортных соединений tcp протокола http

    Рекомендуемый порядок работы с соединениями описан в части 8 RFC 2616.
    Алгоритм таков:

    1. Сервер принимает соединение
    2. Сервер ждёт http-запрос в течении тайм-аута. Если тайм-аут наступает - сервер переходит к 6
    3. Сервер принимает запрос
    4. Сервер отправляет ответ
    5. Сервер переходит к 2
    6. Сервер закрывает соединение


    Старый, описанный в RFC 1945, подход работал по след. алгоритму

    1. Сервер принимает соединение
    2. Сервер принимает запрос
    3. Сервер отправляет ответ
    4. Сервер закрывает соединение

    Т.е. для каждой пары запрос-ответ требовалось создать отдельное TCP-соединение. При использовании нового алгоритма постоянных соединений
    - уменьшается кол-во TCP соединений
    - Уменьшается доля служебных пакетов, открывающих/закрывающих соединения

    • http клиент/сервер: порядок закрытия соединения, !*! devcoder, 12:41 , 11-Июн-09 (4)
      Да, в прикладном уровне (http) всё расписано.
      А меня интересует именно транспорт - tcp.

      • http клиент/сервер: порядок закрытия соединения, !*! ALu, 12:53 , 11-Июн-09 (5)
        >Да, в прикладном уровне (http) всё расписано.
        >А меня интересует именно транспорт - tcp.

        Там имеется ввиду именно TCP транспорт. Читайте и не ленитесь.

        8 Connections

        8.1 Persistent Connections

        8.1.1 Purpose

           Prior to persistent connections, a separate TCP connection was
           established to fetch each URL, increasing the load on HTTP servers
           and causing congestion on the Internet. The use of inline images and
           other associated data often require a client to make multiple
           requests of the same server in a short amount of time. Analysis of
           these performance problems and results from a prototype
           implementation are available [26] [30]. Implementation experience and
           measurements of actual HTTP/1.1 (RFC 2068) implementations show good
           results [39]. Alternatives have also been explored, for example,
           T/TCP [27].

           Persistent HTTP connections have a number of advantages:

              - By opening and closing fewer TCP connections, CPU time is saved
                in routers and hosts (clients, servers, proxies, gateways,
                tunnels, or caches), and memory used for TCP protocol control
                blocks can be saved in hosts.

              - HTTP requests and responses can be pipelined on a connection.
                Pipelining allows a client to make multiple requests without
                waiting for each response, allowing a single TCP connection to
                be used much more efficiently, with much lower elapsed time.

              - Network congestion is reduced by reducing the number of packets
                caused by TCP opens, and by allowing TCP sufficient time to
                determine the congestion state of the network.

              - Latency on subsequent requests is reduced since there is no time
                spent in TCP's connection opening handshake.

              - HTTP can evolve more gracefully, since errors can be reported
                without the penalty of closing the TCP connection. Clients using
                future versions of HTTP might optimistically try a new feature,
                but if communicating with an older server, retry with old
                semantics after an error is reported.

           HTTP implementations SHOULD implement persistent connections.


      • http клиент/сервер: порядок закрытия соединения, !*! Андрей, 19:21 , 11-Июн-09 (6)
        >Да, в прикладном уровне (http) всё расписано.
        >А меня интересует именно транспорт - tcp.
        >

        То как вы будете открывать, закрывать соединения и принимать, отсылать пакеты по TCP зависит от протокола который вы реализуете.

        ALu привёл пример как это сделано в HTTP.
        Если вы пишите свой web сервер то можно следовать этому RFC.
        Если вы пишите что-то своё то вам решать как открывать, закрывать, принимать и отсылать.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру