Transport Layer Interface（TLI、トランスポート層インタフェース）とは、1987年にAT&TのUNIX System V Release 3.0で提供されたネットワーク用APIであり、Release 4 (SVR4) でもサポートが継続された。

 概要 
BSDのソケットに対抗したSystem VのAPIである。TLIは後にThe Open Groupが XTI (X/Open Transport Interface) として標準化した。実装は下位に位置するキャラクタ型入出力機構であるSTREAMSと密接に関連している。

当時、OSIプロトコルが TCP/IP に取って代わると予測されていたため、TLIはOSI参照モデルに準拠したプロトコルから独立した仕様になっており、OSIのトランスポート層に対応している。XTI/TLIを使ったプログラムは、Transmission Control Protocol (TCP)、Xerox Network Systems (XNS)、Systems Network Architecture (SNA)、X.25、Asynchronous Transfer Mode (ATM) などOSI参照モデルの第4層の機能を提供する様々なトランスポート層プロバイダ上で動作可能である。

APIとしてはソケットと同様の機能を提供しているが、ソケットがインターネット・プロトコル・スイートと密接に関連しているのに対し、XTI/TLIはプロトコルから独立している。XTIは、連携するSTREAMSモジュール、ライブラリAPI、ヘッダファイル群、XTIプロセスの動作に関する規則や制限で構成されている。

TLIとXTIはUNIX 98まではPOSIXソケットAPIよりも好まれ、広く使われていた。TLIとXTIは、SolarisなどSVR4から派生したオペレーティングシステム (OS) やUNIXブランド (UNIX 95, UNIX 98, UNIX03 Single UNIX Specification) 準拠のOSでは今もサポートされている。また、Mac OSでもOpen Transportという名称で使われた。UNIX 95 (XPG4) と UNIX 98 (XPG5.2) ではXTIがサポート推奨APIとなっていた。その後Single UNIX SpecificationにおいてSTREAMSを実装していないBSDやLinuxを考慮すべきだという議論が起き、UNIX 03ではSTREAMSとXTIをオプションとし、POSIXソケットをサポート推奨APIとした。

 プロトコル独立性 
XTI/TLIはプロトコルから独立している。しかし、どのプロトコルを使うかを指定する必要があるため、結局アプリケーションは使用するプロトコルについて知っている必要がある。使用するプロトコルに関する知識もアプリケーションから排除するには、Network Selection Facilities を使用する。これはXTI/TLIライブラリ (libnsl) の一部となっている。

 XTI/TLI とソケットの比較 
XTI/TLIとBSDソケットは似ているが、完全に同じというわけではなく、同じ役割の関数が異なる振る舞いをすることも多い。UNIX SVR3 とSVR4 ではTLIとソケットがSTREAMSのTransport Service Interfaceの上に実装されている。

下記の表はPOSIXでのXTIとソケットのインタフェースを比較したものである。

 XTI/TLIインタフェース ソケットインタフェース 意味論的に同一か t_open socket イエス。ただしt_openはオープン時にt_getinfoを実行可能 - socketpair - t_getinfo - - t_getprotaddr getsockname, getpeername イエス。しかしt_getprotaddrは対応する2つの機能を1つで実行可能 t_bind bind, listen イエス。ただしt_bindは対応する2つの機能を1回のコールで実施可能 t_optmgmt getsockopt, setsockopt イエス。ただしt_optmgmtはデフォルト値と調停値を取得できるのに対し、getsockoptとsetsockoptは現在値しか取得/更新できない。 t_unbind bind イエス。ソケットの場合AF_UNSPECを指定することでunbind相当になる。 t_close close イエス。ただし、t_closeでは常にアボート的切断になるのに対し、closeは終了を待ち合わせて解放することもある。 t_getstate - - t_sync - - t_alloc - - t_free - - t_look select, getsockopt selectとgetsockopt (SO_ERROR) はt_lockの全機能をカバーしていない。 t_error perror イエス。ただしXTIは通常のerrnoに追加的にt_errnoを使用し、トランスポート層のエラーだけでなくUNIXシステムのエラーも示すことができる。 t_strerror strerror イエス t_connect connect t_connectの前にt_bindが必須である。 t_rcvconnect select t_rcvconnectは、selectでO_NONBLOCKを指定した場合と同等である。 t_listen, t_accept, t_snddis accept acceptは接続を拒否できないが、t_listenで受け付けた接続要求はその後のt_acceptで初めて許可され、t_snddisを使えば拒否できる。 t_snd, t_sndv send, sendto, sendmsg イエス。しかし t_snd と t_sndv はコネクションモードのトランスポートでのみ使用。 t_rcv, t_rcvv recv, recvfrom, recvmsg イエス。ただしt_rcvとt_rcvvはコネクションモードのトランスポートでのみ使用。 t_snddis close, shutdown t_snddisを発行後も接続要求をlistenし続けることができ、t_connectで接続を再確立することもできる。closeはソケットのファイル記述子を解放してしまう。通信を続ける場合、ソケットでは新たに接続を確立する準備をしなければならない。 t_rcvdis ENOTCONN, ECONNRESET, EPIPE, SIGPIPE イエス。ただし、ソケットではエラーまたはシグナルで通知。 t_sndrel, t_sndreldata shutdown イエス。しかしshutdownには通常解放時にデータを送信する機能はなく、t_sndreldataは通常解放時にデータを送信できる。t_sndrelは単にシャットダウンだけを行う。 t_rcvrel, t_rcvreldata - - t_sndudata, t_sndvudata sendmsg イエス。しかしt_sndudataとt_sndvudataはコネクションレス・モードでのみ使用。 t_rcvudata, t_rcvvudata recvmsg イエス。しかしt_rcvudataとt_rcvvudataはコネクションレス・モードでのみ使用。 t_rcvuderr - - read, write read, write XTI/TLIではread/writeを使用する前にtirdwrモジュールをSTREAMSにプッシュする必要がある。

ライブラリ関数には呼び出し順序の規定があるため、XTI/TLIは状態インジケータを使用しており、ソケットAPIにも同様の仕組みがある。ただし、ソケットのAPI関数は複数の状態で呼び出せることがあるのに対し、XTIのAPI関数は特定の状態でないと呼び出せないようになっている。

 XTI/TLI非同期モード 
XTI/TLIには非同期モードがあり、リアルタイム性が要求されるアプリケーションで利用できる。非同期モードでない場合、データを待ち続けてずっとブロックされる可能性がある。初期化の際に O_NONBLOCK というパラメータを指定すると非同期モードになる。その場合、接続要求、新規データ到着、タイムアウトなどのイベントを非同期にアプリケーションに通知する。

 XTIでの改良点 
XTIでTLIから改良した点として、エラーメッセージの追加、フロー制御のためのイベント追加、パラメータ指定の簡素化（オープンの際はデフォルトでリード・ライトとなるなど）がある。また、t_listenでずっとブロックしてしまうのを防ぐためqlenの値をチェックするようになった。さらにt_strerror()とt_getprotaddr()というインタフェースが追加された。

 実装 
XTI/TLIはUNIX System Vで実装されているが、Linux向けのOpenSS7などの実装例もある。