OSI 7계층
- 물리 Physical
데이터 전기적인 신호로 변환해서 주고 받는 기능을 진행하는 공간
데이터를 전송하는 역할만 진행 - 데이터 링크 Data Link
물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할
Mac 주소를 통해 통신
프레임에 Mac 주소를 부여하고 에러 검출, 재전송, 흐름 제어를 진행 - 네트워크 Network
데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당
라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정, 해당 경로에 따라 패킷을 전달
라우팅, 흐름 제어, 오류 제어, 세그먼테이션 수행 - 전송 Transport
TCP와 UDP 프로토콜을 통해 통신을 활성화
포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공
TCP: 신뢰성, 연결 지향적
UDP: 비신뢰성, 비연결성, 실시간 - 세션 Session
데이터가 통신하기 위한 논리적 연결을 담당
TCP/IP 세션을 만들고 없애는 책임을 지님 - 표현 Presentation
데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당
파일 인코딩, 명령어 포장 압축 암호화 - 응용 Application
응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행
사용자 인터페이스, 전자우편, 데이터베이스 관리
참고
https://gyoogle.dev/blog/computer-science/network/OSI%207%EA%B3%84%EC%B8%B5.html
TCP 3 way & 4 way handshake
3 way handshake
연결 성립
- SYN: 클라이언트가 서버로 통신을 시작하겠다
- SYN+ACK: 서버는 그에 대한 응답
- ACK: 클라이언트는 서버로부터 받은 패킷에 대한 응답
4 way handshake
연결 해제
- FIN: 클라이언트가 서버에게 연결을 종료하겠다
- ACK: 확인했다 / CLOSE_WAIT 상태가 됨
- FIN: 클라이언트에게 연결 종료했다
- ACK: 확인했다 / TIME_WAIT 상태가 됨
참고
https://seomj74.tistory.com/361
TCP/IP (흐름 제어/혼합 제어)
흐름 제어(Flow Control)
endsystem 대 endsystem
송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
reciver가 packet을 지나치게 많이 받지 않도록 조절하는 것
receiver가 sender에게 현재 자신의 상태를 feedback 한다
전송 과정
- Application layer: sender application layer가 socker에 data를 쓴다.
- 아랫단을 거쳐 reciving node로 전송된다. 이때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data를 저장한다.
- application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작한다.
- 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것이다.
- 따라서 receiver는 RWND(Receive WiNDow): receive buffer의 남은 공간을 홍보한다.
수신측보다 송신측의 속도가 빠를 경우 문제가 생긴다.
수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있으며, 만약 손실 되면 불필요하게 응답과 데이터 전송이 송/수신 측 간에 발생한다.
이를 줄이기 위해 송신 측의 데이터 전송량을 수신측에 따라 조절해야 한다.
Stop and Wait
매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송한다.
Sliding Window (Go Back N ARQ)
수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법
전송은 됐지만 ack를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 protocol
먼저 윈도우에 포함되는 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되는 대로 이 윈도우를 옆으로 옮김으로써 그 다음 패킷들을 전송한다.
호스트들은 실제 데이터를 보내기 전에 '3 way handshaking'을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 된다.
혼잡 제어(Congestion Control)
송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 강제로 줄인다.
네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 방지하거나 제거하는 기능
AIMD(Additive Increase / Multiplicative Decrease)
패킷을 하나씩 보내고 문제없이 도착하면 window 크기를 1씩 증가시키며 전송하는 방법
패킷 전송에 실패하거나 일정 시간을 넘으면 패킷의 보내는 속도를 절반으로 줄인다.
초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리며, 혼잡해지는 상황을 미리 감지할 수 없다.
Slow Start(느린 시작)
AIMD와 마찬가지로 패킷을 하나 씩 보내면서 시작하고, 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 윈도우 사이즈를 2배씩 증가 시킨다.
전송 속도는 AIMD에 반해 지수 함수 꼴로 증가한다. 대신에 혼잡 현상이 발생하면 window size를 1로 떨어뜨리게 된다.
처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만, 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있다.
Fase Retransmit(빠른 재전송)
TCP Tahoe
자신의 Timeout 시간이 만료되지 않았어도 바로 보내야 하는 패킷을 전송하는 방식
Fast Recovery(빠른 회복)
TCP Reno
혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법
참고
https://www.brianstorti.com/tcp-flow-control/
https://velog.io/@nnnyeong/Network-TCP-혼잡제어-Congestion-Control
UDP
User Datagram Protocol
데이터를 데이터 그램 단위로 처리하는 프로토콜
비연결형, 신뢰성 없는 전송 프로토콜
데이터 그램 단위로 쪼개면서 전송을 해야 하기 때문에 전송(Transport, 4) 계층
TCP와 UDP는 왜 나오게 됐는가?
- IP의 역할은 Host to Host (장치 to 장치)만을 지원한다. 장치에서 장치로 이동은 IP로 해결되지만, 하나의 장비안에서 수많은 프로그램들이 통신을 할 경우에는 IP만으로는 한계가 있다.
- 또한, IP에서 오류가 발생한다면 ICMP에서 알려준다. 하지만 ICMP는 알려주기만 할 뿐 대처를 못하기 때문에 IP보다 위에서 처리를 해줘야 한다.
1번을 해결하기 위하여 포트 번호가 나오게 됐고, 2번을 해결하기 위해 상위 프로토콜인 TCP와 UDP가 나오게 되었다.
*ICMP : 인터넷 제어 메시지 프로토콜로 네트워크 컴퓨터 위에서 돌아가는 운영체제에서 오류 메시지를 전송받는데 주로 쓰임
그렇다면 TCP와 UDP가 어떻게 오류를 해결하는가?
- TCP
데이터의 분실, 중복, 순서가 뒤바뀜 등을 자동으로 보정해줘서 송수신 데이터의 정확한 전달을 할 수 있도록 해준다. - UDP
IP가 제공하는 정도의 수준 만을 제공하는 간단한 IP 상위 계층의 프로토콜이다. TCP와는 다르게 에러가 날 수도 있고, 재전송이나 순서가 뒤바뀔 수도 있어서 이 경우, 애플리케이션에서 처리하는 번거로움이 존재한다.
UDP는 왜 사용할까?
- UDP의 결정적인 장점은 데이터의 신속성이다. 데이터의 처리가 TCP보다 빠르다.
- 주로 실시간 방송과 온라인 게임에서 사용된다. 네트워크 환경이 안 좋을 때, 끊기는 현상을 생각하면 된다.
DNS(Domain Name Service)에서 UDP를 사용하는 이유
- Request의 양이 작음 -> UDP Request에 담길 수 있다.
- But, TCP를 사용할 때가 있다! 크기가 512(UDP 제한)이 넘을 때, TCP를 사용해야한다.
- 3 way handshaking으로 연결을 유지할 필요가 없다. (오버헤드 발생)
DNS는 Application layer protocol임.
모든 Application layer protocol은 TCP, UDP 중 하나의 Transport layer protocol을 사용해야 함.
그러나 TCP를 사용하는 경우가 있음.
Zone transfer 을 사용해야하는 경우에는 TCP를 사용해야 함.
(Zone Transfer : DNS 서버 간의 요청을 주고 받을 떄 사용하는 transfer)
만약에 데이터가 512 bytes를 넘거나, 응답을 못받은 경우 TCP로 함.
참고
https://gyoogle.dev/blog/computer-science/network/UDP.html#udp는-왜-사용할까
대칭키 & 공개키
대칭키(Symmetric Key)
암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘
기밀성을 제공하나, 무결성/인증/부인방지를 보장하지 않는다.
대표적인 알고리즘: SEED, DES, 3DES, AES, ARIA, ChaCha20
공개키(Public Key) / 비대칭키(Asymmetric Key)
암호화와 복호화에 사용하는 암호키를 분리한 알고리즘
방식
- 암호 모드: 송신자 공개키로 암호화 → 송신자 사설키로 복호화
- 메시지 암호화 목적, 주로 키 교환 용도로 사용
- 인증모드: 송신자 사설키로 암호화 → 송신사 공개키로 복호화
- 메시지 인증(부인방지)가 목적
대표적인 알고리즘: Diffie-Hellman, RSA, DSA, ECC
진행 과정
- A가 웹 상에 공개된 B의 공개키를 이용해 평문을 암호화하여 B에게 전송
- B는 자신의 비밀키로 복호화하여 평문을 확인하고, A의 공개키로 응답을 암호화하여 A에게 보냄
- A는 자신의 비밀키로 암호화된 응답을 복호화하여 확인
하지만 이 방식은 Confidentiallity만 보장해줄 뿐, Integrity나 Authenticity는 보장해주지 못함
→ 이는 MAC(Message Authentication Code)나 전자 서명(Digital Signature)으로 해결
대칭키와 공개키 혼합(하이브리드 방식)
SSL 탄생의 시초
- A가 B의 공개키로 대칭키를 암호화하고 B에게 보냄
- B는 이를 비밀키로 복호화
- B는 A로부터 받은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
- A는 자신의 대칭키로 암호문을 복호화
→ 앞으로 이 대칭키로 암호화 통신 진행
참고
https://velog.io/@gs0351/대칭키-vs-공개키비대칭키
HTTP & HTTPS
HyperText Transfer Protocol
인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
HyperText Transfer Protocol Secure
인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
텍스트를 공개키 암호화 방식으로 암호화한다.
통신 흐름
- 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약한다.
CA란? Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업 - 계약 완료된 CA 기업은 해당 기업의 이름, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
- A서버는 암호화된 인증서를 갖게 되었다.
이제 A 서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 건내준다.
- 클라이언트가 main.html 파일을 A서버에 요청했다. HTTPS 요청이 아니기 때문에 CA기업에서 A 서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
- CA 기업의 공개 키는 브라우저가 이미 알고 있다. 브라우저는 해독한 뒤 A서버의 공개키를 얻게 된다.
- 클라이언트가 A 서버와 Handshaking 과정에서 주고 받은 난수를 조합하여 pre-master-key(대칭키)를 생성한 뒤, A 서버의 공개키로 해당 대칭키를 암호화하여 서버로 보낸다.
- A서버는 암호돠된 대칭키를 자신의 개인키로 복호화하여 클라이언트와 동일한 대칭키를 얻는다.
- 이후 해당 대칭키를 이용해 암복호화를 진행한다.
참고
https://gyoogle.dev/blog/computer-science/network/HTTP%20&%20HTTPS.html
TLS/SSL Handshake
HTTPS에서 클라이언트와 서버 간 통신 전 SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식
- 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보낸다. 이때 암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등을 담는다.
- 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답한다. 이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트에서 handshake 과정 속 암호화에 사용할 공개키를 담고 있다.
- 클라이언트 측은 서버에서 보낸 CA 인증서에 대해 유효한지 CA 목록에서 확인하는 과정을 진행한다.
- CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화한다. 이 난수 바이트는 대칭키를 정하는 데 사용되고, 앞으로 서로 메시지를 통신할 때 암호화하는 데 사용한다.
만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보낸다. - 서버는 클라이언트의 인증서를 확인한 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다.
- 클라이언트는 handshake 과정이 완료되었다면 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보낸다.
- 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보낸다.
- 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고 받을 수 있다.
참고
https://gyoogle.dev/blog/computer-science/network/TLS%20HandShake.html
로드 밸런싱(Load Balancing)
scale-up: 서버 자체의 성능을 확장하는 것
scale-out: 기존 서버와 동일하거나 낮은 성능의 서버를 두 대 이상 증설하여 운영하는 것
하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)
scale-out에서 필요한 것이 로드 밸런싱이다.
분산식 웹 서비스
여러 서버에 부하(Load)를 나누어주는 역할
클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여서 서버에 분산 시켜주는 방식
서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 로드 밸런서로 관리해주면 웹 서버의 부하를 해결할 수 있다.
L4 로드 밸런서와 L7 로드 밸런서가 있다.
L4 로드 밸런서는 포트(Port) 정보를 바탕으로 로드를 분산한다.
한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드 밸런서 이상을 사용해야 한다.
L4 로드 밸런서는 네트워크 계층이나 전송 계층의 정보를 바탕으로 로드를 분산한다. IP 주소, Port 번호, MAC 주소, 전송 프로토콜에 따라 트래픽을 나누는 것이 가능하다.
L7 로드 밸런서는 애플리케이션 계층에서 로드를 분산한다. HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다.
방식
- 라운드 로빈(Round Robin): CPU 스케줄링의 라운드 로빈 방식 활용
- 가중 라운드 로빈: 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분
- 최소 연결(Least Connections): 연결 개수가 가장 적은 서버 선택(트래픽으로 인해 세션이 길어지는 경우 권장)
- IP 해시: 사용자 IP를 해싱하여 분배(특정 사용자가 항상 같은 서버로 연결되는 것을 보장)
- 최소 응답시간: 가장 짧은 응답 시간을 보내는 서버로 트래픽을 할당
장애 대비
로드 밸런서를 이중화하여 대비한다.
참고
https://gyoogle.dev/blog/computer-science/network/Load%20Balancing.html
https://baebalja.tistory.com/476
Blocking/Non-Blocking &Synchronous/Asynchronous
Blocking/Non-Blocking
호출된 함수가 호출한 함수에게 제어권을 건네주는 유무의 차이
함수 A, B가 있다. A안에서 B를 호출했다고 가정해보자. 이때 호출한 함수는 A이고, 호출된 함수는 B가 된다. B가 호출되면서 B는 자신의 일을 진행해야 한다.(제어권이 B에게 주어진 상황)
- Blocking: 함수 B가 할 일을 다 마칠 때까지 제어권을 가지고 있다. A는 B가 다 마칠 때까지 기다려야 한다.
- Non-Blocking: 함수 B가 할 일을 마치지 않았어도 A에게 제어권을 바로 넘겨준다. A는 B를 기다리면서도 다른 일을 진행할 수 있다.
즉, 호출된 함수에서 일을 시작할 때 바로 제어권을 리턴해 주느냐, 할 일을 마치고 리턴해 주느냐에 따라 나뉜다.
Synchronous/Asynchronous
동기/비동기는 일을 수행 중인 동시성에 주목
아까처럼 함수 A와 B라고 똑같이 생각했을 때, B의 수행 결과나 종료 상태를 A가 신경쓰고 있는 유무의 차이라고 생각하면 된다.
- Synchronous: 함수 A는 함수 B가 일을 하는 중에 기다리면서, 현재 상태가 어떤지 계속 체크한다.
- Asynchronous: 함수 B의 수행 상태를 B 혼자 신경쓰면서 처리한다. (Callback)
즉, 호출된 함수(B)를 호출한 함수(A)가 신경쓰는지, 호출된 함수 스스로 신경쓰는지를 동기/비동기라고 생각하면 된다.
비동기는 호출 시 Callback을 전달하여 작업의 완료 여부를 호출한 함수에게 답하면 된다.
참고
HTTP Status Code
- 1xx (조건부 응답)
- 2xx (성공)
- 200(성공) : 서버가 요청을 제대로 처리하거나 제공했다는 의미
- 204(콘텐츠 없음) : 서버에 요청을 성공했으나, 콘텐츠를 제공하지 않음
- 206(일부 콘텐츠) : 서버가 콘텐츠의 일부분만 제공
- 3xx (리다이렉션 완료)
- 301(영구 이동) : 요청한 페이지가 새 위치로 영구적으로 이동
- 304(수정되지 않음) : 마지막 요청 이후 페이지가 수정되지 않았음
- 4xx (요청 오류)
- 400(잘못된 요청) : 요청 자체가 잘못되었음
- 401(권한 없음) : 해당 요청에 대해 사용자의 인증이 되지 않은 상태
- 403(금지됨) : 서버가 요청을 거부함
- 404(찾을 수 없음) : 요청한 리소스를 찾을 수 없음
- 405(허용되지 않는 방법) : 리소스에 맞지 않는 메서드를 사용했을 때
- 5xx (서버 오류)
- 500(내부 서버 에러) : 서버에 오류가 발생해서 응답할 수 없음
- 501(구현되지 않음) : 요청에 대한 서버의 응답 수행 기능이 없음
- 502(불량 게이트웨이) : 게이트웨이가 연결된 서버로부터 잘못된 응답을 받음(보통 서버에 접속자가 폭주해 과부하될 때 발생)
- 503(서비스를 사용할 수 없음) : 서비스를 일시적으로 사용할 수 없음(웹서버 유지보수 혹은 과부하로 인해 다운되었을 때 볼 수 있음)
- 504(게이트웨이 시간 초과) : 서버가 게이트웨이나 프록시 역할을 하고 있거나 연결된 서버와의 응답 지연 발생
- 505(HTTP 버전이 지원되지 않음) : 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않음
참고
https://cocoon1787.tistory.com/514
RESTful API
REpresentational State Transfer
두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
웹을 이용할 때 제약 조건들을 정의하는 소프트웨어 아키텍처 스타일
HTTP URL을 통해 자원(Resource)을 명시하고 HTTP Method(GET, POST, PUT, DELETE)를 통해서 해당 자원에 대한 CRUD(Create, Read, Update, Delete)를 적용하는 것
API란?
애플리케이션 프로그래밍 인터페이스
다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의
개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성한다.
API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있다.
REST 아키텍처 스타일을 따르는 API를 REST API라고 한다. Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다.
REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.
작동 방식
클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속한다.
API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명한다.
- 클라이언트가 서버에 요청을 전송한다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.
- 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다.
- 서버가 요청을 수신하고 내부적으로 처리한다.
- 서버가 클라이언트에 응답을 반환한다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보고 포함된다.
구성 요소
- 자원(Resource): HTTP URL
- 자원에 대한 행위: HTTP Method
- 자원에 대한 표현(Representations)
참고
https://cocoon1787.tistory.com/540
https://aws.amazon.com/ko/what-is/restful-api/
GET & POST
GET
클라이언트가 서버로 데이터를 요청하기 위해 사용
Body 부분은 비어있고 헤더에 Body의 콘텐츠 타입을 명시하는 Content-Type 헤더 필드도 없다.
URL 뒤 쿼리 스트링(Key와 Value)을 붙이고 HTTP 패킷의 헤더에 포함해서 서버에 데이터를 요청한다.
- URL에 정보들이 그대로 노출되기 때문에 POST 방식보다 보안에 취약
- 캐싱 가능 → 전송 속도가 빠름
- 전송하는 데이터 양에 한계가 존재 → 간단한 데이터 요청(게시판의 게시물, 목록 조회)에 적합
- 브라우저 히스토리에 기록이 남음
POST
클라이언트가 서버로 데이터를 전송해 리소스를 추가하거나 생성하기 위해 사용
HTTP 패킷의 헤더에 Body의 콘텐츠 타입을 명시하는 Content-Type 헤더 필드를 포함하고 HTTP 패킷의 Body에는 데이터를 담아서 서버로 전송한다.
- 데이터가 URL에 노출되기 않기 때문에 GET 방식보다 보안적
- 캐싱 불가
- 데이터를 Body에 담기 때문에 데이터 양 제한 없음
- 클라이언트에서 인코딩, 서버에서 디코딩
- 요청받는 시간 제한 존재
- 브라우저 히스토리에 기록이 남지 않음
참고
https://cocoon1787.tistory.com/526
이 외 참고
'Study > CS' 카테고리의 다른 글
| [CS]OS(Operating System) (1) | 2024.06.13 |
|---|---|
| [CS]Computer Architecture - 하드웨어, 시스템 버스, CPU, 캐시 메모리 (2) | 2024.05.29 |