GET vs POST
GET: 주로 데이터를 조회할 때
POST: 데이터를 생성하거나 업데이트할 때 주로 사용
GET 요청: 데이터를 URL의 일부(query string)으로 전송하지만 POST 요청은 데이터를 요청 본문(body)에 포함.
-
GET 요청의 URL 길이에는 브라우저나 서버에 따라 제한이 있음. -> 전송할 수 있는 데이터의 양 제한
URL의 끝에 ? 다음에 키-값 쌍으로.
예시)http://example.com/api?name=John&age=30형태
보안 측면에서 URL에 데이터가 포함되기 때문에 민감한 정보를 GET요청으로 전송하는 것은 권장되지 않음 -
POST 요청
Content -Length(요청 본문의 길이),Content-Type(본문의 미디어 타입)과 같은 추가적인 헤더 정보 필요 (예시:application/json, multipart/form-data)
POST 요청은 GET 요청에 비해 더 많은 데이터를 전송할 수 있으며 데이터가 URL에 노출되지 않기 때문에 더 안전한 방식을 ㅗ간주됨
HTTP 상태 코드
상태코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 코드 - 3자리 숫자 100~500번대 숫자
1xx(정보, Informational): 요청을 받았으며 프로세스를 계속 진행
2xx(성공, Successful): 요청을 성공적으로 받았으며 인식했고 수용
3xx(Redirection): 요청 완료를 위해 추가 작업 조치가 필요
4xx(Client Error): 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
5xx(Server Error): 서버가 명백히 유효한 요청에 대한 충족 실패
404 error: Not found -> 서버가 요청된 리소스를 찾을 수 없을 때 반환
500: Internal Server Error -> 서버가 요청을 처리할 수 없을 때 반환하는 HTTP 상태 코드
TCP 3-way-handshake
3 way handshake는 TCP의 접속, 4-way Handshake는 TCP의 접속 해제 과정
1. 클라이언트가 서버에 SYN 패킷 보내 연결 요청
2. 서버는 SYN-ACK 패킷으로 응답하여 연결 요청을 받았음을 알리고 자신도 연결 준비가 되었음을 나타냄
3. 클라이언트는 ACK 패킷을 서버에 보내 연결 확정
- TCP header에는 Control bit(flag bit, 6 bit)가 존재하며 각각의 비트는 URG-ACK-PSH-RST-SYN-FIN의 의미를 가진다
- SYN(Synchronize Sequence Number)
연결 설정. Sequence number를 랜덤으로 설정하여 세션을 연결하는데 사용.
SYN 패킷은 연결 초기화 과정에서 첫 번째로 전송되며 이 패킷에 포함된 시퀀스 번호는 그 연결에 대한 첫 번쨰 데이터 바이트의 번호로 사용됨
TCP header의 SYN flag
: 연결 요청할 때SYN bit사용
: 연결 요청을 하는 경우 SYN bit 1로 설정
-> SYN bit = 1이면 TCP 연결을 요청하는 과정
: 다른 모든 경우에는 SYN bit = 0
-> 연결 요청에 응답하는 마지막 handshake의 세그먼트에도 SYN bit = 0
SYN 단계에서는 SYN 비트가 설정된 TCP 패킷을 통해 초기 시퀀스 번호 전송
- ACK(Acknowledgement)
: 응답 확인, 패킷을 받았다는 것을 의미
- FIN(finish)
: 연결 해제, 세션 연결을 종료시킬 때 사용. 더이상 전송할 데이터가 없음을 나타냄 -> 4 way handshake에서 사용
- 클라이언트는 SYN bit가 1로 설정된 패킷을 서버에게 보내 연결을 요청합
- 서버는 클라이언트의 요청을 받고, SYN bit와 ACK(Acknowledgment) bit가 모두 1로 설정된 패킷을 클라이언트에게 보내 연결 요청을 수락하고 자신의 시퀀스 번호도 전송
- 클라이언트는 서버로부터 받은 시퀀스 번호를 인정하는 ACK 패킷 전송. 이 때의 패킷에는 SYN bit가 0으로 설정되어 있고, ACK bit만 1로 설정
TCP(Trnasmission Control Protocol)
: 신뢰성있는 데이터 전송을 보장하는 프로토콜
- TCP에서 패킷이 유실된 것을 의심해볼 수 있는 경우
1) 중복된 ACK가 계속해서 오는 경우
2) Timeout이 발생한 경우
TCP는 패킷 손실이 발생하면 자동으로 재전송 시도. 수신자는 받은 패킷에 대해 ACK를 보내고, 송신자는 ACK를 받지 못한 패킷을 재전송한다.
반면 UDP는 패킷 손실에 대해 자체적으로 처리하지 않음. UDP는 확인 응답이나 재전송 기능이 없어 패킷 손실이 발생하면 이를 application level에서 처리해야 한다.
