08:09 입실
순차 프록시 구현하고, 소켓 코드 이해하기
병렬 프록시 구현하기!
순차 프록시
패스와 호스트를 꼭 나눠야 하나?
sprintf(buf, "GET %s HTTP/1.0\r\n", path);
sprintf(buf, "%sHost: %s\r\n", buf, hostname);그렇다. 브라우저는 주소창에서 알아서 나눠서 보내주지만,
프록시 서버는 들어온 uri로 파싱해줘야 함.
새롭게 알게 된 것
- curl로 요청하면 자동으로 http:// 붙어서 감.
- :80을 명시해도 :80은 생략되어서 프록시로 넘어감.
- 이 외의 포트는 그대로 넘어감.
TCP
포트: 프로세스 간의 안정적이고 논리적인 통신 통로
연결 할때는 3way handshake, 종료 할때는 4way handshake
(1)커넥션을 열고, (2) 데이터를 통신하고, (3) 커넥션을을 닫는
일련의 과정을 연결 지향형이라고 함.(connection-oriendted)
TCP에서 소켓이란 IP와 포트를 합한 것
: 인터넷 상에 존재하는 port를 유니크하게 식별하기 위한 주소
UDP
connectionless: 연결을 맺지 않고 바로 데이터를 주고 받는다.
소켓
https://www.youtube.com/watch?v=WwseO8l8rZc
소켓은 프로토콜, ip, port를 조합하여 네트워크 상의 호스트를 유니크하게 식별하는 주소
소켓을 생성하는 게 결국 시스템 콜이었다.
네트워크는 결국 하드웨어를 통해 진행된다.
이때 어플리케이션이 네트워크 기능을 함부러 사용할 수 없으므로,
소켓을 구현해주는 시스템 콜을 통해서 네트워크를 할 수 있게 되고,
이렇게 소켓을 열어서 프로그래밍 하는 방식을 소켓 프로그래밍이라고 함!
포트는 소켓의 식별자이다!!!
MTU
패킷 전송 단위
최대 패킷 데이터 전송 용량을 MTU(Maximum Transmission Unit)라고 하며 표준 MTU는 1500byte임.
일반적으로 TCP헤더와 IP헤더는 각각 20바이트를 차지.
스트림 데이터를 1460씩 잘라서, 각각 TCP와 IP헤더를 붙이면 패킷이 1500byte가 됨!
근데 작은 데이터를 보낼 때마다 패킷을 보내면 패킷이 너무 낭비다.
그래서 버퍼에 데이터를 최대한 채워서 보내는 알고리즘이 nagle(네이글) 알고리즘
BPS & PPS
bps (bits per second):
bps는 초당 비트 수를 나타내는 단위로, 데이터 전송 속도를 측정하는 데 사용됩니다.
네트워크 대역폭, 데이터 전송 속도, 대역폭 제한 등을 나타낼 때 주로 사용됩니다.
예를 들어, 1 Mbps (메가비트/초)는 1초 동안 1,000,000 비트를 전송하는 것을 의미합니다.
pps (packets per second):
pps는 초당 패킷 수를 나타내는 단위로, 네트워크에서 패킷 전송률을 측정하는 데 사용됩니다.
패킷 전송 속도, 네트워크 장비의 처리량 등을 표현하는 데 유용합니다.
예를 들어, 1,000 pps는 1초 동안 1,000개의 패킷을 전송하는 것을 나타냅니다.
3way handshake
이걸 공부를 안 했네..?
퀴즈 나와서 SYN을 SEQ라고 썼다.
ACK도 정확히 이해 못한 상태였음.
클라이언트와 서버 간의 신뢰성 있는 데이터 통신을 구축하는 데 사용
- 클라이언트가 서버에게 요청 패킷 전송
- 서버가 클라이언트에게 요청 수락 패킷 전송
- 클라이언트가 요청 수락 패킷 전송
Step1. SYN(Synchronize)
- 클라이언트가 서버에 연결 요청
- 클라이언트가 TCP 패킷 생성
- 초기 순차 번호(Initial Sequence Number, ISN)과 SYN 플래그가 설정
- 클라이언트는 목적지 서버의 IP와 포트를 목적지로 설정
- 패킷이 클라이언트에서 출발해서 서버 전송
Step2. SYN-ACK(Synchronize-Acknowledgment)
- 서버가 연결 요청 패킷을 받으면 클라이언트에 대한 응답 패킷 생성
- 클라이언트 ISN확인 후 자체 ISN 생성하여 SYN과 ACK(1) 플래그 성성
- 서버에서 출발해서 클라이언트로 전송
- 이 신호는 클라이언트 연결 요청 수락하고, 서버 간 통신이 가능하다는 신호 의미
Step3. ACK(Acknowledgment)
- 클라이언트가 서버의 응답을 확인
- 응답 패킷 수신 후 ACK 플래그를 설정하여 확인
- 패킷을 다시 서버로 전송
- 신뢰성 있는 TCP 연결 설정
3Way handshake 용어 정리
TCP
Transmission Control Protocol
전송 제어 프로토콜
ISN
- Initial Sequence Number
- 각 호스트가 패킷의 순서를 추적하고 데이터의 정확성을 보장하기 위한 순차 번호
- 각 호스트가 자체적으로 고유한 ISN 생성
- 연속적으로 증가하는 시퀀스 번호
- ISN는 최초 핸드쉐이킹에서는 변하지 않으며, 이후 패킷마다 1씩 증가하면서 패킷의 순서를 추적할 수 있게 한다.
- ISN이 패킷 헤더에 있는 건 아니고, ISN을 시작으로 Sequence Number 필드에 값이 담긴다.
Sequence Number
- 이전 sequence numberd에서 1씩 증가하면서 Sequence Number가 설정된다.
- 현재 패킷의 고유번호같은 느낌. 데이터의 순서를 나타낸다.
SYN Flag
- Synchronize
- 동기화 플래그
- 클라이언트가 초기 SYN패킷을 보내면 서버는 응답 SYN-ACK 패킷의 SYN을 클라이언트로부터 받은 SYN플래그로 성정함.
- SYN은 0 또는 1이다.
- SYN이 0이면 일반적인 데이터 패킷이며 연결 설정과 관련 없는 데이터 전송에만 사용됨
- SYN이 1이면 초기 핸드셰이크 프로세스에서 사용되는 패킷이다.
- 즉, SYN 플래그는 초기 핸드셰이킹 단계에서만 1로 설정되며 나머지 단계에서는 0으로 설정된다.
Acknowledgment Flag
- 응답 확인 플래그
- 송신 측에서 수신측으로부터 데이터가 정상 도착했음을 확인하기 위해 ACK 플래그를 설정
- ACK가 0이면 패킷에 아직 응답이 되지 않음. 즉, 초기 핸드셰이크 단계나 데이터 전송 중 사용
- ACK가 1이면 데이터 패킷이 정상적으로 수신되고 응답되었음을 의미. 즉, 수신 측이 데이터를 받았다고 응답할 때 사용
Acknowledgment Number
- 응답 확인 번호
- TCP 패킷 헤더
- 수신 측이 이 전에 받은 데이터를 확인하기 위해 사용
- 서버가 보낸 시퀀스 넘버에서 1을 더한 값으로 설정
3Way handshake 상세 과정
-
(SYN) 클라이언트가 임의의 ISN을 설정 후 이 값을 sequence number 필드에 담아 SYN 플래그 1인 패킷을 서버에 전송. ack number는 0임.(왜냐면 직전에 받은 패킷이 없으니까)
-
(SYN-ACK) 서버는 임의의 ISN을 설정하고 이 값을 sequence number 필드에 담은 후 패킷을 받았음을 확인하기 위해 ACK를 1로 설정하고, 마찬가지로 연결을 요청하기 위해 SYN을 1로 설정하고 패킷을 클라이언트로 전송. 이때 ack number는 클라이언트에서 넘어온 seq number + 1
-
(ACK) 클라이어트는 서버로부터 패킷을 받았음을 나타내기 위해 ACK를 1로 설정하고 패킷을 전송. 이때 이미 연결 요청은 했기 때문에 SYN은 0임. 이때 ack number는 서버로부터 받은 sequence number에 1을 더한 값.
ACK 번호와 ACK 플래그는 다르다!
ACK 번호는 상대방에게 내가 다음에 받아야 하는 패킷 번호를 의미한다.
3way handshake 시나리오
| Stpe | seq number | ack number | ACK | SYN | |
|---|---|---|---|---|---|
| C->S | SYN | 1000(예시) | 0 | 0 | 1 |
| S->C | ACK/SYN | 2000(예시) | 1001 | 1 | 1 |
| C->S | ACK | 1001 | 2001 | 1 | 0 |
4way handshake
TCP가 연결 종료할 때 거치는 과정
4way handshake 상세 과정
-
(FIN) 클라이언트가 Finish 플래그가 설정된 패킷을 서버로 전송
이 플래그는 더 이상 클라이언트가 데이터를 보내지 않겠다고 알림. -
(ACK) 서버는 FIN 패킷을 받았음을 확인하기 위해 ACK가 설정된 플래그를 보냄.
서버는 클라이언트에게 데이터를 안 받겠다고 알림. -
(FIN) 서버도 클라이언트에게 연결 종료를 요청하는 FIN 패킷을 보냄.
서버는 클라이언트에게 데이터를 안 보내겠다고 알림. -
(ACK) 클라이언트는 서버가 보낸 FIN을 받았다는 의미에서 ACK 패킷을 보냄.
클라이언트도 서버에게 데이터를 안 받겠다고 알림.
4way handshake 시나리오
| Stpe | seq number | ack number | ACK | FIN | |
|---|---|---|---|---|---|
| C->S | FIN | 1000(예시) | 0 | 0 | 1 |
| S->C | ACK | 2000(예시) | 1001 | 1 | 0 |
| S->C | FIN | 3000(예시) | 1001 | 0 | 1 |
| C->S | ACK | 1001 | 3001 | 1 | 0 |
데이터 전송과 연결, 종료는 각각 다른 단계이다.
따라서 시퀀스 넘버를 새롭게 설정된다.
ARP
내부 네트워크를 너무 크게 잡으면 안 되는 이유!
ARP에서 브로드캐스팅을 할 때 호스트가 많으면 과부하
적절한 수 많큼만 서브네팅으로 네트워크를 구성하는 게 좋음!
NAT
Network Address Translation
IP 패킷 주소 정보 변환
대표적으로 공인IP와 사설IP 변환
포트포워딩으로 포트도 변경할 수 있음.
내부 아이피를 외부 아이피로 변환 : SNAT 출발지 주소 변환 (Source)
외부 아이피를 내부 아이피로 변환 : DNAT 목적지 주소 변환 (Destinaion)
NAT = SNAT + DNAT
GET vs POST
GET은 요청 시 Body가 없다. 그래서 데이터를 전송해야 할 때는 URI에 쿼리 스트링 형태로 삽입해서 나간다. 즉, 전송 데이터가 HTTP Header에 실려서 나간다. URI에 실릴 수 있는 데이터 양이 제한되어 있다. 일반적으로 2048바이트 이하가 권장되며 제한 크기는 브라우저, 서버, 웹 표준에 따라 다르다.
GET은 캐싱이 쉽고, 브라우저에 기록이 남으므로 보안이 취약하다.
POST는 Body에 데이터를 실어서 나갈 수 있다. 그래서 헤더에 Content-Length와 Content-Type같은 추가 헤더 정보(필수)가 필요하다.
