Comment le bit de push TCP a été modifié pour Windows NT 3.5

Traductions disponibles Traductions disponibles
Numéro d'article: 123749 - Voir les produits auxquels s'applique cet article
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Agrandir tout | Réduire tout

Résumé

La pile TCP/IP pour Windows NT version 3.5 a été entièrement repensée. Cet article traite d'une des nombreuses améliorations de performances implémentées ; mettre un terme à la gestion améliorée du bit TCP PUSH sur la réception.

Plus d'informations

Le protocole TCP a un peu dans chaque en-tête appelé le PUSH bit. RFC 1122 section 4.2.2.2 contient le texte suivant sur le bit PUSH.

   4.2.2.2  Use of Push: RFC-793 Section 2.8

      When an application issues a series of SEND calls without
      setting the PUSH flag, the TCP MAY aggregate the data
      internally without sending it. Similarly, when a series of
      segments is received without the PUSH bit, a TCP MAY queue
      the data internally without passing it to the receiving
      application.

      The PUSH bit is not a record marker and is independent of
      segment boundaries. The transmitter SHOULD collapse
      successive PUSH bits when it packetizes data, to send the
      largest possible segment.

      A TCP MAY implement PUSH flags on SEND calls. If PUSH flags
      are not implemented, then the sending TCP: (1) must not
      buffer data indefinitely, and (2) MUST set the PUSH bit in
      the last buffered segment (i.e., when there is no more
      queued data to be sent).

      The discussion in RFC-793 on pages 48, 50, and 74
      erroneously implies that a received PUSH flag must be passed
      to the application layer. Passing a received PUSH flag to
      the application layer is now OPTIONAL.

      An application program is logically required to set the PUSH
      flag in a SEND call whenever it needs to force delivery of
      the data to avoid a communication deadlock. However, a TCP
      SHOULD send a maximum-sized segment whenever possible, to
      improve performance (see Section 4.2.3.4).

      DISCUSSION:
         When the PUSH flag is not implemented on SEND calls,
         i.e., when the application/TCP interface uses a pure
         streaming model, responsibility for aggregating any
         tiny data fragments to form reasonable sized segments
         is partially borne by the application layer.

         Generally, an interactive application protocol must set
         the PUSH flag at least in the last SEND call in each
         command or response sequence. A bulk transfer protocol
         like FTP should set the PUSH flag on the last segment
         of a file or when necessary to prevent buffer deadlock.

         At the receiver, the PUSH bit forces buffered data to be
         delivered to the application (even if less than a full
         buffer has been received). Conversely, the lack of a
         PUSH bit can be used to avoid unnecessary wakeup calls
         to the application process; this can be an important
         performance optimization for large timesharing hosts.
         Passing the PUSH bit to the receiving application allows
         an analogous optimization within the application.
				


L'utilisation de côté de la réception du bit PUSH a été modifiée dans Windows NT version 3.5. Dans Windows NT version 3.1, TCP/IP avait un comportement comme si le bit PUSH toujours été défini par l'expéditeur. Par conséquent, il exécutées application recv() appels dès que toutes les données n'étaient disponibles. Dans Windows NT version 3.5, la logique de réception a été optimisée pour utiliser le bit PUSH. Cela réduit le nombre de fois où qu'une application doit se réveiller pour les données entrantes. Toutefois, lorsque NT communique avec une implémentation de TCP/IP (ou application) qui ne définit pas le bit PUSH moments opportuns, de performances peuvent en souffrir.

Performances se dégradent car, lorsque les données arrivent sans le PUSH bit défini, TCP maintient recv() de l'application en attendant que le reste des données. Windows NT version 3.5 TCP/IP se termine un recv() appeler quand :

  • Données arrivent avec le jeu de bits PUSH.

    - ou -
  • La mémoire tampon de recv() l'utilisateur est pleine.

    - ou -
  • 0,5 secondes écoulées depuis l'arrivée de toutes les données.
Lorsque le troisième test complet ci-dessus est nécessaire pour terminer un appel recv(), les performances se dégradent.

L'exemple suivant montre comment la gestion améliorée du bit TCP PUSH peut améliorer les performances :

   A client-server pair is going to transfer 4096 bytes between them on
   Ethernet. The client application executes a send() for 4096 bytes.
   Windows NT TCP/IP breaks the 4096 bytes into three Ethernet packets:

      1460 bytes, no PUSH
      1460 bytes, no PUSH
      1176 bytes, PUSH is set

   At the same time, the server executes recv(), for 8192 bytes. When the
   first packet arrives, TCP puts the data into the user buffer. The same
   thing happens for the second packet since PUSH is still not set.
   However, when the third packet arrives, TCP completes the recv() because
   PUSH was set.
				


Dans ce scénario, maintenant sur les performances de renforcements recv() en raison de la surcharge implicite dans chaque appel recv() ; au lieu d'effectuer trois appels à recv(), l'application ne établit qu'un seul, retournant toutes les 4 096 octets. Si le client n'a pas défini l'indicateur PUSH sur le troisième paquet, TCP envoyaient pas recv() pour un autre 0,5 secondes. Étant donné que certaines implémentations de TCP/IP (et les applications) jamais la valeur PUSH, ils ont tendance à médiocres avec Windows NT version 3.5 TCP/IP.

Propriétés

Numéro d'article: 123749 - Dernière mise à jour: jeudi 27 février 2014 - Version: 2.1
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows NT Workstation 3.5
  • Microsoft Windows NT Workstation 4.0 Édition Développeur
  • Microsoft Windows NT Server 3.5
  • Microsoft Windows NT Server 4.0 Standard Edition
Mots-clés : 
kbnosurvey kbarchive kbmt kbnetwork KB123749 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 123749
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com