컴퓨터 망 CH3. Transport Layer

Alpha, Orderly·2023년 3월 8일

컴퓨터 망

데이터 망

목록 보기

3/8

Transport Layer

Network Layer에서 제공하는 서비스를 Application Layer에서 사용 가능 하도록 변환한다.
다른 Host에서 동작하는 Application proccess 사이의 논리적-커뮤니케이션(Logical-Communication)을 제공한다.
Transport protocol이 End system에서의 Action
- Sender : Application 메시지를 세그먼트(Segment)로 분리하여 Network layer에게 보낸다.
- Receiver : 분리된 Segment를 메시지로 새로 합쳐서 Application layer로 보낸다.
TCP와 UDP가 대표적인 예시

Transport layer

Process들 간 통신

Network layer

Host간 통신

Transport Layer Action

송신자

Application layer 메시지를 받는다.
Segment header의 Field value를 정한다.
Segment 생성
Segment를 IP로 보낸다.

수신자

IP로부터 Segment를 받는다.
Header value를 확인한다.
Application layer 메시지를 추출(Extract) 한다.
소켓을 통해 Application으로 메시지를 Demultiplex 한다.

두가지 중요한 Transport protocol

TCP Transmission Control Protocol

신뢰성 있고 순서가 유지된다.
혼잡제어
흐름제어
연결 설정 과정이 있다.
데이터 경계가 없다.

UDP User Datagram Protocol

신뢰성이 없고 순서가 유지되지 않는다.
데이터 경계가 있다.
거품이 없는(no-frill) 최선의 노력을 다하는(Best-effort) IP의 확장(Extension)

둘 다 불가능한것

지연시간 보장
대역폭 보장

Multiplexing

Sender

여러 소켓으로부터 전달된 데이터를 관리(Handle)하여, Transport header를 붙힌다.
- Transporter header는 Demultplexing에 사용된다.

Demultiplexing

Receiver

헤더에 적힌 정보를 이용하여 전달받은 Segment를 올바른 소켓에 배송한다.

작동법

Host가 IP Datagram을 받는다.
- 각각의 데이터그램은 아래의 값을 가진다.
  - 송신IP, 수신IP
  - 1개의 Transport layer segment
  - 송신 포트번호, 수신 포트번호
Host는 IP주소와 포트번호를 이용하여 Segment를 올바른 소켓으로 전달한다.

Connectionless Demultiplexing

소켓 생성시 자기 자신(Host-local)의 포트번호를 작성해야 한다.
UDP 소켓으로 전송할 Datagram 생성시 목적지의 IP주소와 포트번호를 작성해야 한다.
수신자가 UDP Sement를 받으면 수신자 포트 번호를 확인해 올바른 소켓에 보낸다.
- 목적지 IP, 포트가 같은데 Source가 다른 경우에도 같은 소켓에 전송됨

Connection-oriented demultiplexing

TCP 소켓은 다음과 같은 4개의 값(4-Tuples) 으로 구분된다.

Source IP 주소
Source 포트번호
Destination IP 주소
Destination 포트번호

이 4개의 값을 전부 받아 Segment를 올바른 소켓으로 보낸다. - Demux

TCP는 여러개의 소켓 작동을 지원한다.
각각의 소켓은 자신만의 4-Tuple로 구분된다.
각각의 소켓은 다른 연결된 Client와 관련있다.

UDP User Datagram Protocol

"장식이 없는/no frills", "기본적인/bare bone" 인터넷 프로토콜
Connectionless Transport
- 일정한 전송 통로가 정해져있지 않다.
최선을 다하는(Best-effort) 서비스로, UDP Segment는 손실되거나 순서가 뒤바뀐채로 App에 전송될수 있다.

Protocol Control Information

보통은 제어 정보를 의미합니다. 주소, 오류 검출 코드, 프로토콜 제어 정보등이 있습니다. 이러한 정보를 붙이는 것을 캡슐화라고 합니다.

Service Data Unit

전송하려는 데이터를 의미합니다.
length : 자기 자신의 크기
checksum : 에러 체크

사용

멀티미디어 스트리밍 앱 < 손실은 괜찮고 속도는 빨라야함 >
DNS
SNMP
HTTP/3

특징

연결 수락 과정이 없음 ( RTT 낭비 없음 )
Connection state가 없어 간단함
헤더 크기 작음
혼잡제어 기능이 없다.

UDP에 신뢰성있는 전송이 필요할 경우 ( ex. HTTP/3 )

Application layer에 필요한 신뢰성을 추가한다.
Application layer에 혼잡제어를 추가한다.
QUIC

실제 사용시

Sender

Application message를 받는다.
UDP Segment 헤더를 정한다.
UDP Segment 를 생성한다.
Segment를 IP로 보낸다.

Receiver

IP로부터 Segment를 받는다.
헤더값의 UDP Checksum을 확인한다.
Application layer 메시지를 추출한다.
소켓을 통해 Application message를 Demultiplex 한다.

UDP Checksum

전송받은 Segment에서 에러(Ex. Flipped bit)를 검출한다.

Sender

UDP Segment의 Content를 16비트 정수의 나열로 취급(Treat) 한다.
Checksum : Segment content의 합
체크섬의 값은 UDP Checksum field에 넣는다.

Receiver

받아온 Segment의 Checksum을 계산한다.
계산된 Checksum과 실제 checksum을 비교하여 같으면 에러가 없는것이고 다르면 에러가 있는것이다.
- 물론 같아도 에러가 있을수 있다 : 2비트 이상의 에러가 있는 경우
Checksum을 계산하는 과정에서 덧셈의 MSB에 비트가 초과할수 있는데, 이는 다시 1의자리로 넘겨 더해준다.

UDP의 장점

Setup / Handshaking과정이 없다 -> RTT 발생(incurred) 하지 않음

Reliable Data Transfer

송수신하는 Channel은 패킷 손실, 패킷 오염, 순서 섞임 등의 비신뢰적(Unreliable) 특성을 가진다.

송신자와 수신자는 서로의 상태를 알지 못한다
- 메세지를 받았는지의 여부
단방향 데이터 전송을 고려해 만든다.

Reliable data transfer protocol (rdt) 인터페이스

각각의 API 정의
헤더/Protocol Control Information 추가

FSM / Finite state machine

프로토콜 기술 방법

예시

rdt1.0 : Reliable Channel & Reliable Transfer

Channel에 Bit error도 없고 Packet loss도 없다.
즉, 채널이 완전무결하다.

rdt_send()로 전송 요청시 패킷을 만들어 udt_send()로 보낸다.
rdt_rdv()로 받아올시 여기서 패킷을 Decapsulation 해 전달한다.
수신할때 검사하지 않고 바로 추출및 받는다.

rdt2.0 : Channel with bit error

Channel에 Bit flip이 생길수 있다. > 에러가 생길수도 있다.
Checksum과 같은 방식으로 Bit error를 감지할수 있다.
이 에러를 복구하는 방법
- ACK : 수신자가 송신자에게 패킷을 잘 받았다고 직접적으로 이야기한다.
- NAKs : 수신자가 송신자에게 패킷에 에러가 있었다고 직접적으로 이야기한다.
  - NAK를 받은 송신자는 패킷을 재전송한다.
  - STOP AND WAIT
    - 송신자가 패킷을 하나 보내고 수신자의 응답을 기다린다. 재전송 방식중 하나.

Sender

rdt_send() - 전송
- 체크섬 만들어 전송함
ACK나 NAK을 기다림
ACK면 다음패킷 전송, NAK면 재전송

Receiver

rdt_rcv() 수신
잘 왔으면 ACK 보내주고 에러 있으면 NAK 보내줌

rdt 2.1 : ACK가 오염된다면?

송신자는 수신자에게 어떤일이 일어났는지 알수 없다.
그저 새로 보낸다 -> 중복 패킷이 전달될수 있다.

어떻게 처리? - Stop and Wait에서의 사례.

보내 놓고 ACK 올때까지 기다린다.

송신자가 중복된 패킷을 보낼때 각각의 패킷에 번호(Sequence Number)를 붙힌다.
- 2개의 번호면 충분하다
- 새로 전송하기 전에 ACK를 확인하고 보내기 때문에 이미 전송된 패킷은 단 한개 뿐이기 때문이다.
수신자는 번호를 확인해 중복된 패킷을 버린다.
- 1번 받아야 하는데 0번 오면 버림.
- 수신자는 ACK/NAK가 손상된 사실을 모른다.
이전에 보냈던 패킷의 번호를 기억해야 하기에 상태(State)가 두배가 된다.

Sender

Receiver

rdt 2.2 : NAK-Free protocol

rdt2.1과 유사하게 작동하나 ACK만을 사용한다.
NAK 대신 수신자는 마지막 패킷을 잘 받았다고 보낸다.
- 이때 ACK에 마지막으로 받은 패킷의 번호를 붙힌다.
- ACK(1) - 1번 패킷을 잘 받았다는 의미
- 1번 패킷 보냈는데 ACK(0)을 보냈다는것은 1번 패킷을 받지 못했다는것과 동일하다.
수신자가 ACK를 받았을때 번호가 중복될 경우 재전송한다.
- NAK으로서 작동한다.

rdt 3.0 : 에러와 손실이 있는 Channel

수신자가 ACK를 "적당한 시간"(Reasonable time) 만큼 기다린다.
패킷이나 ACK가 너무 늦게오면
재전송이 발생한다.
이를 위해 반드시 수신자는 받은 패킷의 번호를 ACK에 적어줘야 한다.
전송과 동시에 타이머가 시작한다.
ACK를 받으면 타이머가 사라진다.

rdt 3.0의 성능 ( Stop-and-Wait )

U_sender : 송신자가 보낸다고 바쁜 시간의 비율

예시
- 1Gbps Link, 15ms prop delay, 8000bit packet
- transmission delay는 0.008ms
- 전송에 걸린 시간 / 전체 걸린 시간
- L / R -> Transmission delay
- RTT = 2 * Propagation delay

Stop-and-Wait의 성능은 너무 별로다,
프로토콜이 성능을 제한하게 된다.

rdt 3.1 : Pipelined protocols operation

pipelining : 송신자가 여러개의 ACK가-곧-될(yet-to-be-acknowledged) 패킷을 보낼수 있게 한다.
Utilization이 그나마 나아진다.
최대 한번에 Propagation Delay / Transmission Delay 개를 보낼수 있다.

Data Link 계층에서는 Stop-and-Wait을 Automatic Repeat reQuest / ARQ 라 부른다.

Go-Back-N

Sender

Window : 한번에 ACK 없이 전송 가능한 최대의 크기
송신자 입장에서 N개 길이의 연속적으로 전송되나 ACK되지 않은 패킷을 가짐
cumulative ACK
- ACK(n): n번 패킷까지 잘 받았다는 의미
- ACK(n)을 받으면 n+1자리로 Window의 시작점을 옮겨준다.
ACK 되지 않은 가장 오래전에 전송된 패킷을 기준으로 타이머가 동작한다.
Timeout 발생시 ACK를 받지 못한 가장 오래된 n번째와 Window 에 포함된 이후 패킷을 전송한다.

Receiver

현재까지 잘 받은 패킷의 ACK만 보낸다. 보내는 ACK의 번호는 가장 순서가 높은 번호를 보낸다.
중복 ACK를 보낼수도 있다, rcv_base가 기억해야한다.

순서가 올바르지 않은 패킷을 받을떄
- 버리거나 버퍼에 저장한다.
- 순서가 올바르지 않기 직전 가장 높은 패킷 번호로 ACK를 보낸다.
송신자가 재전송을 한다.

Selective repeat

수신자가 모든 제대로 받은 패킷에 대해 개별적으로 ACK를 보낸다.
- Cumulate ACK가 아니다!
- 필요하면 패킷을 버퍼에 저장한다.
송신자는 ACK되지 않는 패킷을 따로 재전송한다.
- 송신자는 각각의 ACK되지 않은 패킷의 타이머를 보관해 둔다.
- 모든 전송되는 패킷에 Timeout 을 측정한다!
송신 윈도우
- N개의 연속된 번호
- 보내는 양에 제한을 둔다.

pkt2의 ACK가 오지않아 Timeout 된 예시

selective repeat dilemma

Window size가 3일때

받는 입장에서 패킷이 재전송된 이전 패킷인지 새로 전송된 다음 패킷인지 알수 없는 문제 발생

순서번호가 윈도우에 비해 너무 작기 때문에 벌어지는 일
순서번호의 갯수를 윈도우 크기의 2배와 같거나 크게 해주면 된다.

TCP

TCP SEGMENT 구조

RST-유효하지 않은 연결 거부, SYN-연결시작시 1로 설정, 첫번째 전송 위치를 주고받음, FIN-연결 종료에 사용한다.
ACK에 대한 ACK는 받지 않는다.
Flow Control : 수신 측에서 받을수 있는 바이트의 수, option에 이 값에 곱할수 있는 scaling factor를 적어 놓을수 있다.
C, E : 혼잡제어에 사용
P : 바로 수신되어야 되는 데이터인지 확인, 어플리케이션이 바로 필요한 데이터인지
U : Urgent pointer가 유효한 것인지를 나타낸다. Urgent pointer란 전송하는 데이터 중에서 긴급히 전당해야 할 내용이 있을 경우에 사용한다. 긴급한 데이터는 다른 데이터에 비해 우선순위가 높아야 한다.

Point to Point (점대점 연결)
- 1 Sender <> 1 Receiver
Reliable / In-order byte (신뢰성 있고 순서유지됨)
- no Message boundary
- 송신 함수의 호출 횟수와 수신 함수의 호출 횟수가 일치하지 않아도 된다 == 데이터의 경계가 없다
- 보낸 문자열들을 한번의 수신함수 호출로 전부 받아올수 있다.
Full duplex data
- 동일 연결로 양방향 데이터 전송
- MSS : Maximum segment size
  - 1 Segment의 최대 크기가 제한된다.
  - 네트워크 카드의 MTU를 기준으로 정해진다.
Cumulative ACK
Pipelining
- TCP 혼잡/흐름 제어를 통해 윈도우 사이즈를 결정한다.
Connection-oriented:
- 논리적 Connection 이 생성되고 데이터가 송수신된다.
- Handshaking(Control message exchange)가 데이터 교환 이전에 성사된다.
Flow controlled
- 송신자가 수신자의 버퍼가 넘치지 않게 한다(Overwhelm)

TCP 패킷 구조

Sequence number
- Sequential Number : 송신시 전송하는 시작 바이트의 순번
- ex) 300byte 의 데이터를 100byte 씩 나눠서 보낼 때 첫 패킷은 0, 두번째는 100, 세번째는 200 이다.
Acknowledgement
- 상대방이 다음에 전송해야할 순서번호
- 패킷을 잘 받았으니 다음 패킷을 보내라는 뜻이다.
순서가 다른 Segment의 처리
- TCP로 처리 불가능, Implementor에 따라 다름
Checksum
- IP정보를 포함하는 Pseudo-header를 포함하여 계산한다.
options와 header length
- options를 포함한 헤더의 길이를 ACK 바로 아래 head len 에 기록한다.
- head len의 길이의 제한으로 options 부분의 길이는 제한된다.

Piggybacking - 데이터 전송과 ACK를 동시에 하는것 - TCP

이를 위해 ACK와 Seq number가 전부 Segment에 존재한다!

양방향으로 ACK는 받은 Seq 번호 + 1이 되는것을 볼수 있다!

TCP Timeout

RTT보다는 길어야 한다, 즉 갔다가 오는 시간보다는 길어야 한다는것. 허나 RTT는 항상 다르다!
TCP Timeout이 너무 짧으면
- 너무 빠른 Timeout 발생한다.
- 불필요한 재전송이 발생한다.
TCP Timeout이 너무 길면
- Segment loss에 대해 늦은 반응을 보인다.

RTT 예측법

SampleRTT
- segment가 전송되고 ACK를 받기까지의 시간을 측정한다.
- RTT를 Smoother하게 예측할수 있다.
- 최근 측정된 값들의 평균을 사용하는것.
$\alpha$ : 새로 측정된 시간의 가중치, 보통 0.125를 사용한다.
Timeout Interval
- Estimated RTT + "Safety Margin"
Safety margin
- 보통 EstimatedRTT의 편차(DevRTT) * 4의 값을 사용한다.
편차 계산 : 차이의 절댓값을 사용한다는것을 주의한다.
$\beta$ 의 값은 보통 0.25 정도이다.

TCP sender

Sequential Number를 이용해 Segment를 만든다.
타이머가 실행중이지 않으면 시작한다.
- 타이머는 가장 오래된 ACK를 받지못한 Segment를 위한것이다.
- 타이머 구간 벗어남 : TimeOutInterval

Timeout

타임아웃을 일으킨 Segment를 재전송한다.
타이머 재시작

ACK 받음

ACK 받았다고 Update한다.
ACK 못받은게 여전히 있으면 타이머를 시작한다.

TCP Receiver

Event

Segment가 순서대로 예상한 Seq Number과 함께 도착. 예상한 Seq Number까지 이미 ACK 보냈음
-> ACK 지연, 500ms정도 다음 Segment를 기다리다가 안오면 ACK를 보내서 요청함
Segment가 순서대로 예상한 Seq Number과 함께 도착. 한 Segment가 ACK를 보내지 않았음
-> 즉시 단일 ACK를 전송 및 요청
Segment가 마구잡이로 예상보다 큰 Seq Number과 함께 도착.
-> 즉시 중복 ACK를 보낸다. 이는 받기를 예상한 byte의 Seq Number이다.

마지막 ACK ( ACK=120 )은 92는 이미 받았고 내가 필요한건 120 Seq Number Segment라는것이다.

Cumulative ACK 덕분에 오류가 발생하지 않았다.

TCP fast retransmit

만약 송신자가 똑같은 데이터를 요청하는 3개의 ACK를 받았을 경우 ACK 되지 않은 가장 작은 Seq Number를 가진 Segment를 전송한다.

TCP Flow control

Network layer가 Application layer에서 가져가는것보다 데이터를 더 빨리 가져온다면?

receive window / rwnd : 수신자가 받아오기를 희망하는 바이트 크기를 지정한다
수신자가 송신자를 관리해, 송신자가 너무 많은 데이터를 빠르게 전송해 버퍼 오버플로우가 생기는것을 방지한다.

HOW

TCP 수신자가 rwnd 필드를 통해 사용 가능한 버퍼 공간의 크기를 공시(Advertise) 한다.
- RcvBuffer : 수신버퍼, OS에 의해 자동으로 조절되며 대체로 4096바이트.
수신자는 rwnd값을 토대로 전송되는/ACK를 받지못한 데이터의 양을 조절한다.
수신 버퍼가 오버플로우 되지 않도록 보장한다.

TCP Connection Management

데이터 교환하기 이전에 송-수신자들은 Handshake를 한다.
- 연결을 성사하기 위한 동의
- 시작 Sequential Number과 같은 Parameter들에 대한 동의

2-way handshake

서버가 클라이언트에 패킷을 보내는 SYN이 없다.

요청을 재전송할수도 있다.

TCP 3-way handshake

Client가 SYNbit를 1로 하고 Seq x를 정해 요청
Server가 SYNbit를 1로 하고 Seq y를 정해 요청과 동시에 ACK는 x+1을 보냄 ( 다음 바이트 순서 요청 )
Client가 ACK를 y+1로 해서 보냄

belay 자일을 매다

TCP 연결 닫기

Client와 Server 모드 자신의 연결을 닫는다.

FIN을 받아 ACK로 응답한다.
- FIN을 받았을시 ACK는 자가 자신의 FIN과 같이 보낸다.
동시적인 FIN 교환이 이루어진다.

Congestion Control 혼잡제어

Congestion

네트워크가 감당하기엔 너무 많은 Source가 너무 많은 Data를 빠르게 보내는것.
증상
- 긴 딜레이 : 라우터 버퍼에서 기다리는 시간
- 패킷 손실 : 라우터에서 버퍼 오버플로우

예시 1

R의 속도를 가지는 단일 라우터에 N개의 연결이 존재

사용하는 대역폭이 R/2를 넘어서는 순간
- 나가는 속도보다 들어오는 속도가 더 빨라져 딜레이가 무한이 된다.

예시 2

버퍼가 한정된 라우터의 경우
송신자가 손실되거나 타임아웃된 패킷을 새로 보낸다.

예시 3

송신자는 라우터 버퍼가 있을때만 데이터를 보낸다.

예시 4

패킷이 손실될수도 있다
송신자는 패킷이 손실되었음을 알았을때에만 재전송한다.

but sender times can time out prematurely, sending two copies, both of which are delivered

"Congestion"의 COST

주어진 수신 Throughput에 대해 재전송으로 인한 더 많은 작업량
필요하지 않은 재전송

최대 Throughput보다 느리게 된다.

예시 5

빨간색 in이 늘어나면 윗쪽의 패킷은 drop된다
파란색 Throughput은 0이 된다.

X 축 : 보내는 양 | Y축 : 받는 양
또다른 Congestion의 cost
- 패킷이 손실되면 거기까지 가는데 소요된 버퍼와 송신 대역은 낭비된 셈이 된다.

정리

Throughput은 Capacity를 넘을수 없다.
Capacity에 도달하면 Delay가 증가한다.
패킷손실/재전송은 실질 Throughput을 감소시킨다.
필요하지 않은 재전송 또한 실질 Throughput을 감소시킨다.
패킷 손실이 일어날 경우 그간 사용된 버퍼와 대역폭은 낭비된것이 된다.

해결 - 시험에 나올듯

End-End congestion control

패킷 손실과 패킷 지연을 통해 혼잡 상태를 추정한다.
직접적인 정황이나 피드백은 없다.
TCP에 의해 작동된다.

Network assisted congestion control

라우터가 직접적으로 송수신 호스트에 피드백을 보낸다.
Congestion level이나 sending rate을 정해준다.
TCP ECN, ATM, DECbit

TCP Congestion control

AIMD - Additive Increase Multicative Decrease : 선형 상승 지수 하강

송신자는 패킷 손실이 일어나기 전까지 송신 속도를 올리다 패킷 손실이 일어나면 줄인다.
세번 중복된 ACK 받으면 속도를 절반으로 줄인다.
타임아웃으로 손실되면 1개의 최대 세그먼트 크기(MSS / Maximum Segment size)정도로 속도를 줄인다

AIMD : Distributed Asynchronous Algorithm

optimize congested flow rate
desirable stability

Detail

cwnd바이트만큼 보낸 뒤 ACK를 기다리기 위해 RTT만큼 기다린다
더 많은 데이터를 전송한다.

파일 전송 제한
cwnd = 마지막으로 보낸양 - 마지막으로 ACK된양
- ACK 되지 않은 데이터의 양
증가량은 cwnd보다는 작거나 같아야 한다!

TCP slow start

처음엔 1 cwnd만큼 보냈다 다음엔 2배로 늘려나간다.
느렸다가 매우 빨라진다.
지수적인 속도 증가가 linear해야 할 타이밍은?
- slow start threshhold / ssthresh를 정해서 결정한다.

구현

ssthresh 변수 정함
패킷 손실시 ssthresh는 패킷 손실 직전 속도의 절반이 된다.

reno와 tahoe는 방식의 이름중 하나이다.

TCP Cubic

AIMD보다 더 나은 방법
W_max : 패킷 손실이 측정된 속도
W_max가 그리 크게 변하지 않았을것이라 예측함
절반으로 속도가 줄어들었으면 빠르게 Wmax에 가깝게 속도가 늘어나되, 근처에 다가가면 다시 속도증가가 느려짐

이름 외우기_

K : TCP 윈도우 사이즈가 W_max에 도달하는데 걸리는 시간

Bottleneck link

TCP 속도가 특정 라우터의 패킷 손실이 일어나기 전 까지 증가 : 병목 Link가 존재한다.

Delay-based TCP congestion control - tcp-vegas

측정 처리량 : $\frac{마지막 RTT에 전송된 바이트}{측정된 RTT}$
RTT_min : 최소 측정 RTT
혼잡이 없을때 얻을수 있는 가장 큰 처리량은 cwnd/RTT_min
- 측정 처리량이 비혼잡에 가까울 경우 cwnd를 증가
- 측정 처리량이 혼잡에 가까울 경우 cwnd를 감소
손실을 강제하지 않는 congestion control
지연시간을 최대한 적게 유지하면서 처리량을 최대로 함

tcp-bbr : 구글에서 만듦

Explicit congestion notification ( ECN )

Network Assisted congestion control

IP 헤더의 두 비트(ToS/Type of Service 필드)가 네트워크 라우터에 의해 혼잡 정도를 확인하는 용도로 사용된다.
혼잡 정도가 목적지에 도착한다
목적지에서 TCP의 C, E 비트를 설정해 ACK Segment로 보내서 송신지에 혼잡을 공지한다.
- E 비트 : ACK에 담아 보내는 혼잡 알림
- C 비트 : 자신이 E 비트를 받아 cwnd를 줄였음을 알림
IP와 TCP 모두가 사용된다.