Computer Science Knowledge Storage

GET 및 POST는 서버에서 특정 동작을 요청하는 데 사용되는 HTTP 메서드입니다.

GET은 주로 조회할 때 사용되고, 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있습니다. 서버에게 동일한 요청을 여러번 전송하더라도 동일한 응답이 돌아와야 한다는 성질을 가지고 있습니다.

POST는 서버에게 동일한 요청을 여러번 하더라도 응답은 항상 다를 수 있습니다. POST는 주로 서버의 상태나 데이터를 변경할 때 사용하는데 생성에는 POST만을 사용하고 수정과 삭제에는 더 알맞는 메소드를 사용하는 것이 좋습니다.

TCP 3 way handshake는 가상회선을 수립하는 단계입니다.

클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정을 통하고 SYN, ACK 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고 ACK 플래그에 1을 더한 값을 전송합니다.

TCP 4 Way handshake
TCP 4 way handshake는 TCP 연결을 해제하는 단계이다.
클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하여 클라이언트에게 이를 받았음을 알리는 패킷을 전송하여 연결이 해제된다. 이때 서버는 클라이언트에게 소켓이 닫혔다고 통지해도 클라이언트 측에서 일정시간 대기한다. 그 이유는 통지 패킷이 나중에 도착할 수 있기 때문이다.

TCP는 연결 지향형 프로토콜이고 가상 회선을 만들어 흐름제어, 혼잡제어, 오류 제어를 통해 신뢰성을 보장하지만 속도면에서 느리므로 파일 전송과 같은 신뢰성이 중요한 서비스에 이용합니다.

반면 UDP 는 데이터를 데이터그램 단위로 전송하는 프로토콜로 신뢰성을 보장하는 절차는 따로 없지만 빠르게 데이터를 보낼 수 있으며 스트리밍과 같은 연속성이 중요한 서비스에 사용됩니다.

HTTP와 HTTPS 모두 응용 계층에서 클라이언트-서버 간 리소스를 요청하고 제공을 담당하는 프로토콜이다.

HTTP는 서버에서 클라이언트로 전송되는 데이터가 암호화되지 않는 평문 통신을 하기 때문에 도청을 하거나, 완전성을 증명할 수 없기에 변조가 가능하다는 보안 취약점을 가진다. 또한 통신 상대를 확인하지 않기 때문에 위장이 가능하다.

HTTPS는 이러한 HTTP의 단점을 해결합니다. HTTPS는 HTTP의 일반 텍스트에 SSL이나 TLS 프로토콜로 씌워 데이터를 암호화하는 기법으로 인증기관 CA에서 받은 개인키와 암호키를 기반으로 클라이언트와 서버간에 통신의 완전성을 도입합니다.

그 절차는 다음과 같습니다. 첫째로 클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보냅니다. 이후 클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속 요청 서버가 신뢰할 만한지 검증하고 검증이 완료되면 클라이언트는 대칭키를 생성합니다. 클라이언트는 대칭키를 서버의 공개키로 암호화하여 서버에게 전송한뒤, 서버는 캐인키로 대칭키를 복호화 한뒤 대칭키를 통해 데이터를 주고 받습니다.

이러한 과정을 통해, 기밀성과 무결성, 인증이 가능합니다.

HTTP 1.1은 HTTP 1.0과 다르게 지속 연결이 가능합니다. 이를 통해 네트워크 자원을 최적화할 수 있고 지연시간이 줄어 성능이 향상 합니다. 또 캐싱 기능이 가능하며 상태 코드를 추가하여 클라이언트에서 서버 응답을 구체적으로 대응할 수 있습니다.

HTTP2는 멀티 플렉싱과 헤더 압축 기능 및 서버 푸시가 있습니다.

멀티 플렉싱은 다중 스트림으로 구현하여 채널이 비어있을 때 충돌이 줄어들어 네트워크 효율성을 높입니다. 
헤더 압축은 HPACK이라는 헤더 압축을 이용하여(호프만) 요청 및 응답 헤더 크기를 줄입니다.

서버 푸시는 클라이언트의 요청 없이 서버가 클라이언트에게 리소스를 미리 푸시할 수 있습니다. 이를 통해 웹 페이지 로딩 속도가 빨라집니다.

응용 계층과 전송 계층 사이의 인터페이스 socket을 이용하여 세그먼트를 프로세스에게 전달합니다. 각 socket에는 매핑되어 있는 port 넘버가 있고, port 넘버는 호스트에서 실행중인 프로세스를 구분합니다. 이 포트 넘버를 소켓에 바인딩하고 데이터를 보낼 때에는 트랜스포트 레이어에서 제공하는 포트 멀티플렉싱을 합니다.

데이터를 받을 때에는 전송계층은 세그먼트 헤더의 대상 포트넘버를 검사하여 디멀티플렉싱을 통해 포트넘버와 연관된 소켓을 찾아 데이터를 넘겨줍니다.

많은 소켓의 생성과 삭제에서 발생할 수 있는 오버헤드를 줄일 방법은 소켓을 풀에 유지하여 관리하는 방법입니다.

연결이 필요한 경우 풀에서 사용 가능한 소켓을 할당하고 연결이 닫히면 다시 풀에 반환하여 관리하면 소켓이 재사용되므로 생성 및 삭제의 오버헤드를 줄일 수 있습니다.

또 다른 방법으로 TCP는 소켓 재사용을 허용하므로 새 소켓을 만들 필요없이 새로운 주소와 포트로 바인딩하여 소켓을 재사용하는 방법이 있습니다. 만약 응용 프로그램에서 허용하는 경우라면 영구 연결을 사용하여 소켓의 생성 및 삭제의 오버헤드를 줄일 수 있습니다.

Selective ack 일 때 N+1번 세그먼트에 대한 ACK가 도착했다는 것은 N에 대해서도 패킷이 도달했다는 것을 알 수 있습니다.

TCP는 accumulative ack로 ack를 매 패킷마다 보내지 않을 수 있고, 순서대로 마지막에 받은 패킷에 대한 ack를 보낼 수 있습니다.

따라서 N+1번 세그먼트에 대한 ACK가 도착했다는 것은 N번 세그먼트에 대해서도 도달했다는 것을 알 수 있고, window사이즈만큼 sliding window를 이동시켜 다음 패킷을 보낼 준비를 합니다.

네트워크 레이어의 목적으로는 크게 라우팅과 포워딩이 있습니다.

라우팅은 출발지에서부터 목적지로까지 최적의 경로를 결정합니다. 라우팅 프로토콜과 알고리즘을 사용하여 정체 및 비용과 같은 요소를 기반으로 최적의 경로를 결정합니다.

포워딩은 라우팅을 통해 최적의 경로가 밝혀지면 결정된 경로를 따라 해킷 헤더의 목적지 주소를 검사하여 long prefix 알고리즘을 바탕으로 다음 노드로 데이터 패킷을 전달하는 역할을 합니다.

전송 계층과 네트워크 계층 모두 체크섬을 사용하여 전송된 데이터의 무결성을 보장합니다. 그러나 체크섬은 다른 용도로 사용됩니다.

TCP 또는 UDP 체크섬과 같은 전송 계층 체크섬은 데이터가 소스 호스트와 대상 호스트 간에 오류 없이 전송되었는지 확인하는 데 사용됩니다. 체크섬은 전송 계층 헤더 및 데이터 필드의 내용을 기반으로 계산됩니다. ⇒ 데이터 포함

반면 IPv4 또는 IPv6 체크섬과 같은 네트워크 계층 체크섬은 데이터가 src 네트워크와 dest 네트워크 간에 오류 없이 전송되었는지 확인하는 데 사용됩니다. 체크섬은 네트워크 계층 헤더 및 데이터 필드의 내용을 기반으로 계산됩니다. ⇒ 헤더 체크

즉, 전송 계층 체크섬은 단일 네트워크 연결 내에서 종단 간 오류 탐지 기능을 제공하는 반면 네트워크 계층 체크섬은 여러 네트워크 연결에 걸쳐 오류 탐지 기능을 제공합니다. 이러한 이중화는 컴퓨터 네트워크에서 데이터 전송의 안정성과 무결성을 보장하는 데 도움이 됩니다.

응용 프로그램에서 TCP/IP 기반으로 생성하는 것으로 응용프로그램과 transport layer를 연결해주는 역할로, 두 머신이 네트워크를 통해 서로 통신할 수 있도록 양쪽에 생성되어 서로 다른 프로세스가 양방향, 실시간 통신을 할 수 있게 해주는 interface입니다.

소켓이 구현됨으로써, 네트워크 및 전송 계층의 캡슐화가 가능해집니다.

HTTP 프로토콜은 connectionless를 지향하고 stateless protocol로써 리소스의 낭비를 줄여주지만 매 통신마다 클라이언트가 인증이 필요합니다.

쿠키와 세션은 이 단점을 보완하는 기술인데 두 기술의 가장 큰 차이는 저장위치로, 쿠키는 클라이언트에 세션은 서버에 저장됩니다. 그래서 쿠키는 빠르지만 보안에 취약하고, 세션은 느리지만 상대적으로 보안성이 좋습니다.

또 쿠키는 브라우저가 종료되어도 남아있지만 세션은 삭제된다는 차이가 있습니다. 따라서 보안성이 중요할때에는 세션을, 종료시에 유지되기 위해서는 쿠키를 사용해야합니다. 하지만 세션의 경우 서버의 자원을 사용하는 것이므로 사용자가 많아지면 자원 관리면에서 문제가 발생할 수 있습니다.

세션은 서버에서 사용자의 id와 pw를 비교하여 세션 저장소에서 세션 id를 넘겨주고 사용자의 정보를 저장합니다. 클라이언트가 서버에게 정보를 보낼때 쿠키에 세션 id를 포함해서 같이 보내 서버는 세션 저장소에서 사용자임을 알 수 있고, 이전에 사용자가 했던 통신을 이어서 할 수 있게 합니다.

JWT는 서버에서 발급하는 것으로, 따로 저장소 없이 사용자의 고유 id 값을 보유하고 서버는 토큰을 검증 이후 조작 여부와 유효기간을 확인합니다. 검증이 완료되면 payload를 디코딩하여 사용자의 id에 맞는 데이터를 가져옵니다.

가장 큰 차이는 Session 저장소에 유저의 정보를 넣는 반면 JWT는 토큰 안에 유저의 정보를 넣습니다.

1. 연결 설정: TCP 3방향 핸드셰이크는 송신자와 수신자 사이의 연결을 설정하는 데 사용됩니다. 여기에는 송신자의 SYN(동기화) 패킷, 수신자의 SYN-ACK(동기화-확인) 패킷 및 송신자의 ACK(확인) 패킷이 포함됩니다.
2. 시퀀스 번호: TCP는 전송된 각 데이터 바이트에 고유한 시퀀스 번호를 할당합니다. 이렇게 하면 수신기가 올바른 순서로 데이터를 재구성할 수 있습니다.
3. ACK: 수신기는 ACK 패킷을 전송하여 데이터의 성공적인 수신을 확인합니다. 보낸 사람이 지정된 시간 초과 기간 내에 ACK를 수신하지 않으면 승인되지 않은 데이터를 재전송합니다.
4. Selective ack 및 Go-Back-N: TCP는 선택적 반복 또는 Go-Back-N 메커니즘을 사용하여 손실되거나 순서가 잘못된 패킷을 처리할 수 있습니다. Selective ack 을 통해 수신기는 특정 손실 패킷을 승인하고 재전송할 수 있는 반면 Go-Back-N은 손실된 패킷 이후 모든 후속 패킷을 재전송해야 합니다.

TCP는 Sliding window를 이용하여 흐름제어를 구현합니다. 수신 측에서 설정한 윈도우 크기만큼 송신측에서 ACK 없이 세그먼트를 전송할 수 있게 데이터를 동적으로 조절하는 기법입니다. 수신측은 윈도우 사이즈가 바뀔때마다 송신측에게 윈도우 사이즈를 보낼 수 있고, 송신측은 그에 따른 데이터 바이트 크기만큼 확인 응답없이 계속해서 보낼 수 있습니다. 만약 ACK가 왔다면 그만큼 윈도우를 이동하면 됩니다.

윈도우 사이즈는 수신측에서 받을 수 있는 바이트 수를 의미하는데 호스트들은 데이터를 보내기 전에 윈도우 사이즈 크기를 수신 호스트의 윈도우 사이즈 크기에 맞춥니다.

따라서 TCP는 window size에 따라 sliding window로 흐름 제어를 구현합니다.

먼저 타임아웃이 있습니다. 송신측에서 설정한 RTO보다 RTT가 더 크면 패킷이 타임아웃되어 손실되었다고 생각하여 패킷을 다시 보냅니다. 해당 방법은 동작이 느리므로 네트워크의 지연을 초래할 수 있습니다.

그 대안으로 Fast Retransmission이 있습니다. Fast Retransmission은 중복된 ACK가 세개가 되었을 시에 송신측에서 패킷이 유실되었다고 하여 패킷을 다시 보내는 것을 말합니다. 또 패킷을 보낼때에는 Go-back-N 방식이 아닌 Selective Retransmission으로 네트워크 리소스를 절약하고 효율성을 향상 시킬 수 있습니다.

TCP는 혼잡제어를 AIMD와 slow start가 있습니다.

AIMD는 처음 패킷을 하나씩 보내고 문제없이 도착하면 window size를 1씩 증가시켜 전송하는 방식입니다. 만약 패킷 전송에 실패하면 그때의 패킷을 절반으로 줄이고 다시 window 사이즈를 1씩 증가합니다. 하지만 이 방법은 초기 네트워크에 많은 리소스를 사용하지 못하므로 많은 시간이 걸립니다.

slow start는 전송 속도를 늦게 올리는 AIMD와 다르게 window size를 지수형태로 증가합니다. 만약 혼잡현상이 발생하면 window 사이즈를 1로 떨어뜨리고 다음 1씩 증가합니다. fast recovery도 있는데 혼잡현상이 발생했을 때 window 사이즈를 1로 낮추는 것이 아닌, window 사이즈를 반으로 낮추어 그 window size에서 1씩 증가하는 방법입니다.