Привет.

Регулируется ли чем (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
  • http клиент/сервер: порядок закрытия соединения,devcoder, 08:22 , 10-Июн-09
• http клиент/сервер: порядок закрытия соединения,ALu, 11:07 , 11-Июн-09
  • http клиент/сервер: порядок закрытия соединения,devcoder, 12:41 , 11-Июн-09
    • http клиент/сервер: порядок закрытия соединения,ALu, 12:53 , 11-Июн-09
    • http клиент/сервер: порядок закрытия соединения,Андрей, 19:21 , 11-Июн-09

Если отправил всё что хотел, закрывай сокет на отправку (shutdown), читай остатки что присылает другая сторона и жди пока она закроет, или соединение оборвётся, или сам закрой спустя таймаут.

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

>Если отправил всё что хотел, закрывай сокет на отправку (shutdown), читай остатки
>что присылает другая сторона и жди пока она закроет, или соединение
>оборвётся, или сам закрой спустя таймаут.

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

>Привет.
>
>Регулируется ли чем (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) всё расписано.
А меня интересует именно транспорт - tcp.

>Да, в прикладном уровне (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) всё расписано.
>А меня интересует именно транспорт - tcp.
>

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

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