1. TCP vs UDP
  2. TCP : handshake
  3. SSL/TLS
  4. REST
  5. cookie vs session

TCP vs UDP

[간단하게]

TCP와 UDP는 transport layer에서 전달받은 데이터를 다음 계층에 전달해주는 역할을 합니다. TCP는 신뢰성이 있고, 응용 입장에서 데이터가 전송된 순서대로 도착하는것처럼 보이게 합ㅂ니다. 또한 좀 더 안정적인 서비스를 위해 둘 사이 통신을 하기 전 먼저 connection을 설정해서 데이터들의 error나 flow를 제어합니다. 반면 UDP는 신뢰성이 없으며 순서가 어긋날 수도 있습니다. transport layer가 제공해야하는 가장 기본적인 서비스만 제공합니다. 하지만 따라서 UDP는 TCP보다 훨씬 간단하여 속도가 빠르다는 장점이 있습니다.

[구체적으로]

TCP는 신뢰성이 있는 protocol로 error, flow, congestion을 control 해줍니다. TCP는 connection-oriented service로 둘 사이 통신하기 전 먼저 connection을 설정해서 데이터들의 error나 flow들을 제어하여 안정적인 서비스를 제공하고자 합니다. TCP의 error control은 보내는 데이터의 에러가 없도록 해줍니다. 이는 에러가 없어질 때까지 재전송함으로써 이루어집니다. flow control은 sender가 receiver가 받을 수 있는 용량 이상의 데이터를 한꺼번에 보내지 않도록 조절해주며 congestion control은 데이터를 중간의 라우터나 스위치에 쌓이지 않도록 제어해줍니다. TCP는 연결을 우선시하며 개발 당시에는 멀티미디어 데이터가 없었고 security에 대한 위험성도 감지하지 못했기 때문에 지연시간, security등은 보장해주지 못한다는 단점이 존재합니다.
반면 UDP는 신뢰성이 없는 protorol입니다. TCP가 제공하는 error control, flow control, congestion control을 제공하지 않습니다. 데이터가 깨지면 깨진대로 전달합니다. 즉 UDP는 transport layer protocol의 기본적인 multiplexing, demultiplexing 기능만 하는데 대신 TCP보다 전반적으로 속도가 빠르다는 특성이 있습니다.
각 데이터의 특성이 다르기 때문에 TCP를 요구하는 것이 있고 UDP를 요구하는 것이 있습니다.

UDP
-multiplexing
-demultiplexing

TCP : handshake

[구체적으로]

TCP 연결을 수립할 때 3-way handshake과정을 거치고 연결을 해지할 때 4-way handshake과정을 거칩니다. handshaking은 데이터를 주고받기 전에 sender와 receiver 상태를 초기화 시킵니다.
TCP 연결을 하기 위해서는 client가 server에게 SYNbit=1을 보내며 연결을 요청하며 sequence number를 넘겨줍니다. 서버에서 이것을 받으면 서버도 SYNbit=1로 연결을 허락함을 알려주고 다른 Sequence number와 함께 보낸 데이터를 잘받았다는 의미로 ACK bit를 1로, ACKnum를 받은 sequence number에 1 증가시켜 클라이언트에 전송합니다. 마지막으로 client가 서버가 살아있음을 확인하고 그에 대한 응답으로 ACKbit를 1로 ACKnum을 받은 sequence number에 1 증가시켜 서버에 전송함으로써 연결이 수립됩니다. 이러한 과정이 3-way handshake 과정입니다.
연결을 해지하기 위한 4-way handshake 과정은 클라이언트 쪽에서 서버쪽으로 연결을 끊고싶다는 의미로 FINbit를 1로 Sequence number와 함께 서버에 전달하면서 시작됩니다. 이를 받은 서버는 ACKbit를 1, ACKnum을 받은 Sequence number에 1을 증가시켜 보냄으로써 클라이언트에서 서버쪽의 연결을 끊습니다. 아직 서버에서 클라이언트 쪽의 연결은 남아있으므로 서버가 FINbit를 1 Sequence number와 함께 보냄으로써 연결을 끊고싶어함을 클라이언트에게 알려줍니다. 이를 받은 클라이언트는 ACKbit를 1 ACKnum을 받은 Sequence number에 1 증가시켜 보냅니다. 이로써 서버와 클라이언트 클라이언트와 서버 사이의 연결이 모드 끊기게 됩니다.

-SYNbit : 연결 설정. Sequence Number를 랜덤으로 설정하여 세션을 연결하는 데 사용하며, 초기에 Sequence Number를 전송한다.
-Seq(Sequence number) : 송신자가 지정하는 순서 번호, 전송되는 바이트 수 기준으로 증가
-ACKbit : 응답 확인. 패킷을 받았다는 것을 의미한다.
-FINbit : 연결 해제. 세션 연결을 종료시킬 때 사용되며, 더 이상 전송할 데이터가 없음을 의미한다.

SSL/TLS

참고 : https://babbab2.tistory.com/4

[구체적으로]

TCP와 UDP는 암호화되어있지 않아서 HTTP 메세지도 TCP를 쓰게 되면 모든 정보가 open된다는 단점이 있습니다. 이를 보완하기 위해 SSL/TLS는 TCP에 얹혀져서 HTTP에 암호화하는 기능을 제공하는 프로토콜로 application layer에 해당됩니다. 데이터 무결성을 보장하며 TCP로 연결된 두 디바이스가 서로 자신을 인증할 수 있도록 해줍니다. TLS는 SSL 3.0버전을 더 발전시킨것으로 SSL보다 속도가 좀 더 느린 특징이 있습니다.
SS/TLS는 대칭키 방식과 비대칭키 방식을 둘 다 사용합니다. 처음 대칭키를 서로 공유하는 통신을 RSA 비대칭키 방식을 이용하고, 실제 통신을 할 때는 CPU 리소스 소모가 적은 대칭키 방식으로 데이터를 주고받습니다.
어떤 클라이언트가 서버에 접속하면서 안전한 SSL연결을 만들자고 requst를 보냅니다. 서버가 특정한 암호 코드가 들어있고 이것으로 암호화한 데이터는 이 서버만 다시 풀어볼 수 있는 cetificate를 알려줍니다. 클라이언트는 이후에 자신들이 사용할 암호 키를 certificate 정보로 암호화해서 서버에 전달합니다. 이 암호화된 정보는 서버만 해석할 수 있기 때문에 서버만 암호키를 알아 볼 수 있고 외부에서는 암호화 키를 알지 못하기 때문에 해석하지 못하게 됩니다.
-symmetric key : 암호화하는 키와 복호화하는 키가 동일함, 대칭키를 전달하는 과정에서 해킹당할 위험이 있다
-asymmetric key : 대칭키 암호화의 근본적인 문제를 해결하기위해 나온것, 한 쌍의 키를 가짐(public/private key), 하나의 키로 암호화하면 다른 하나의 키로 복호화가 가능하다(RSA 알고리즘)

-RSA 알고리즘 :
왜 SSL/TLS는 대칭키 방식과 비대칭키 방식을 같이 사용할까
RSA알고리즘을 이용한 암호화 방식은 복잡한 수로 이루어져 있어 CPU 리소스를 크게 소모하는 단점이 있다. RSA 비대칭키 방식으로만 통신을 하기에는 성능상 어려움이 있다.

REST

[간단하게]

REpresentational State Transfer의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든것을 의미합니다. REST API 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다 말합니다.

[구체적으로]

HTTP URI를 통해 자원을 명시하고 HTTP method를 통해 해당 자원에 대한 CURD operation을 적용하는것을 REST라고 합니다. 따라서 자원인 HTTP URI, 자원에 대한 행위인 HTTP method, 자원에 대한 행위의 내용으로 구성되어있습니다. REST는 client-server architectur, statelessness, cacheability, layered system, uniform interface 라는 특징을 가집니다. 즉 REST는 실제 데이터와 유저에 대한 정보가 분리되어있어야하고, client의 현재 상황을 서버에 저장하면 안되며, 서버의 response가 client나 중간의 웹캐시 같은 곳에 저장이 가능해야합니다. 또한 클라이언트가 접속할 때 서버에 직접 접속된 상태인지 중간의 웹 프록시 서버에 접속된 것인지 구별할 수 없어야하며 표준화된 언어를 사용해서 특정한 컴퓨터 architecture에 제약받지 않는 서비스를 해야합니다.
REST API는 REST의 원리를 따른 API를 의미하는데 몇가지 규칙이 존재합니다. URI는 동사보다는 명사를 대문자보다는 소문자를 사용해야하며 마지막에 슬래시를 포함하지 않아야하고 언더바 대신 하이폰을 사용하고 파일 확장자는 URI에 포함하지 않으면서 행위 또한 포함하지 않아야합니다. 이러한 설계 규칙들을 올바르게 지킨 시스템을 RESTful 하다고 합니다.

장단점
장점 : HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없으며 HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다. REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
단점 : 표준이 존재하지않아 정의가 필요합니다. 사용할 수 있는 메소드가 4가지밖에 없습니다. 브라우저를 통해 테스트 할 일이 많은 서비스라면 Header 정보의 값을 처리해야 하므로 전문성이 요구됩니다. 또한 구형 브라우저에서 호환이 되지 않아 PUT과 DELETE와 같이 지원이 안되는 부분이 존재합니다.

-URI
-CRUD : 기본적인 데이터 처리 기능인 Create(POST), Read(GET), Update(PUT), Delete를 말함.
-Hypermedia API :

참고 : https://dev-coco.tistory.com/161
참고 : https://dev-coco.tistory.com/61

[간단하게]

쿠키는 클라이언트의 로컬에 저장되는 키와 값의 작은 데이터입니다. 텍스트 형식으로 저장되며, 브라우저 종료 시에도 로컬에 남아있고 도메인당 20개, 쿠키당 4KB의 제한이 있습니다.
세션은 일정시간동안 같은 브라우저로 들어오는 일련의 요구사항을 하나의 상태로 보고 그 상태를 유지하는 기능입니다. 서버에 오브젝트 형식으로 저장되며 브라우저 종료 시 사라집니다.

[구체적으로]

HTTP 프로토콜은 비연결을 지향하고 상태 정보를 유지 안한다는 특징이 있습니다. 즉, 서버와 클라이언트는 통신이 끝나면 상태 정보를 유지하지 않습니다. 따라서 서버는 클라이언트가 누구인지 계속 인증을 해줘야하는데 이러한 번거로움을 해결하는 방법이 쿠키와 세션입니다.
쿠키는 클라이언트의 로컬에 저장되는 키와 값의 작은 데이터입니다. 텍스트 형식으로 저장되며, 브라우저 종료 시에도 로컬에 남아있고 도메인당 20개, 쿠키당 4KB의 제한이 있습니다.
세션은 일정시간동안 같은 브라우저로 들어오는 일련의 요구사항을 하나의 상태로 보고 그 상태를 유지하는 기능입니다. 서버에 오브젝트 형식으로 저장되며 브라우저 종료 시 사라집니다.
쿠키와 세션은 비슷한 역할을 하는데 이는 세션도 결국 쿠키를 사용하기 때문입니다. 가장 큰 차이점은 쿠키는 서버의 자원을 사용하지 않고 세션은 서버의 자원을 사용한다는 점에 있습니다. 쿠키는 클라이언트의 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약합니다. 하지만 세션은 쿠키를 이용해서 seesion id만 저장하고 그것으로 구분하여 서버가 처리하기 때문에 비교적 보안면에서 더 우수합니다. 쿠키는 만료기간이 있지만 파일로 저장이 되기 때문에 브라우저를 종료해도 정보가 유지되고 세션은 만료기간을 정할 수 있지만 브라우저가 종료되면 만료기간에 상관없이 삭제된다는 차이점도 있습니다. 또한 쿠키는 쿠키에 정보가 들어있기 때문에 요청 시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 냅니다.

왜 쿠키를 사용할까?
세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이윤느 세션은 서버에 저장되고, 서버의 자원을 사용하기때문에 서버 자원에 한계가 있고, 속도가 느려질 수 있어서 자원관리 차원에서 쿠키와 세션을 적절히 사용함으로써 서버 자원의 낭비를 방지하고 속도를 높일 수 있기때문입니다.

+캐시
캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소이고 쿠키와 세션은 정보를 저장하기 위해 사용됩니다. 캐시는 웹 페이지를 빠르게 렌더링 할 수 있게 도와주고 쿠키와 세션은 사용자의 인증을 도와줍니다.

study 준비

참고 : https://mangkyu.tistory.com/91
참고 : https://kangsu-2ji.tistory.com/160?category=968182

  • 로드 밸런싱에 대해 설명하고 로드 밸런서가 서버를 선택하는 방식을 설명해주세요.
    • 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결해주는 서비스입니다.
    • 로드밸런서가 서버를 선택하는 방식에는 우선 round robin 방식이 있습니다. 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식입니다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합합니다. 트래픽으로 인해 세션이 길어지는 경우 권장하는 연결 개수가 가장 적은 서버를 선택하는 방식이 있으며 IP 해시 방식이 있습니다. 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식입니다. 사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장합니다.
  • 쿠키와 세션의 동작 방식에 대해 설명해주세요.
    • 쿠키의 경우 웹 브라우저가 서버에 요청하면 상태를 유지하고 싶은 값을 쿠키로 생성합니다. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 쿠키를 포함해서 전송합니다. 전달받은 쿠키는 웹브라우저에서 관리하고 있다가, 다음 요청 때 쿠키를 HTTP 헤더에 넣어서 전송하면 서버에서는 쿠키 정보를 읽어 이전 상탱정보를 확인한 후 응답합니다.
    • 세션의 겨애우 웹 브라우저가 서버에 요청하면 서버가 해당 웹브라우저(클라이언트)에 유일한 ID(Session ID)를 부여합니다. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 Session ID를 포함해서 전송합니다. 웹브라우저는 이후 웹브라우저를 닫기까지 다음 요청 때 부여된 Session ID가 담겨있는 쿠키를 HTTP 헤더에 넣어서 전송하면 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답합니다.
  • OSI 7계층중 1, 2, 3계층에 대해 간단히 설명해주세요.
    • 1계층은 Physical Layer입니다. 데이터를 전기 신호로 바꾸어주는 계층으로 단위는 bit입니다. 단지 데이터 전달 역할만을 하고 알고리즘이나 오류 제어 기능은 존재하지 않습니다. 예를 들어 허브, 케이블, 라우터, 전원 스위치 같은 것이 이것에 해당합니다.
    • 2계층은 Data Link Layer입니다. 노드 간 데이터 전송을 제공하며 물리 계층의 오류 수정도 처리합니다. 물리적인 연결을 통해 인접한 두 장치간의 신뢰성있는 정보 전송을 담당하며 단위는 frame이고 이더넷이 여기에 해당합니다.
    • 3계층은 Network Layer입니다. 네트워크의 라우터 기능이 있어 컴퓨터나 서버끼리의 연결에서 라우터가 이 작업을 효율적으로 처리합니다. 라우터가 여기에 해당하며 Packet단위로 움직입니다.
    • 나머지 계층?
      • 4계층은 Transport Layer입니다. 최종 시스템 및 호스트 간의 데이터 전송을 담당합니다. 보낼 데이터의 용량, 속도, 목적지 등을 처리하고 Segment 단위로 움직이며TCP, UDP가 여기에 해당합니다.
      • 5계층은 session Layer로 컴퓨터끼리 통신을 하기 위해 세션을 만드는 계층입니다.
      • 6계층은 Presentation Layer로 데이터의 형식(Format)을 정의하는 계층입니다. 코드간의 번역을 담당합니다.
      • 7계층은 Application Layer로 사요ㅑㅇ자에게 통신을 위한 서비스를 제공합니다. 인터페이스 역할을 합니다.
    • 라우터와 스위치의 차이는?
      • 라우터는 3계층 장비로, 수신한 패킷의 정보를 보고 경로를 설정해 패킷을 전송하는 역할을 수행하는 장비
      • 스위치는 주로 내부 네트워크에 위치하며 MAC 주소 테이블을 이용해 해당 프레임을 전송하는 2계층 장비
  • TCP의 3 way handshake와 4 way handshake에 대해 설명해주세요.
  • HTTP의 문제점을 설명하고 보완할 수 있는 방법에 대해 말해주세요.
    • SSL/TLS
    • TCP/IP 구조의 통신은 전부 통신 경로상 엿볼 수 있습니다. SSL을 사용하여 통신 자체를 암호화하거나 콘텐츠 자체를 암호화하여 보완할 수 있습니다. 또한 통신 상대를 확인하지 않기 때문에 위장이 가능합니다. HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있습니다. 이 문제점 또한 SSL로 해결 가능합니다. SSL은 상대를 확인하는 수단으로 cetificate를 제공합니다. 제 3자 기관에서 발행되기 때문에 서버나 클라이언트가 실재하는 사실을 증명하고 신뢰할 수 있습니다. 정보의 정확성을 증명할 수 없어 변조가 가능하다는 문제점도 있는데 이 또한 SSL을 적용한 HTTPS를 사용하여 해결합니다.


  • TCP/UDP에 대해 설명해주세요.
  • CORS란?
    • Cross-Origin Resource Sharing의 약자로 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여합니다. 브라우저는 보안 상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한합니다. 웹 애플리케이션을 개선시키기 위해, 개발자들은 브라우저 벤더사들에게 XMLHttpRequest가 cross-domain 요청을 할 수 있도록 요청했고 이에 따라 CORS가 생겼습니다. 따라서 다른 서버의 리소스를 불러오기 위해서는, 그 출처에서 CORS에 대한 내용을 Response의 헤더에 추가해줘야 합니다. 그에 따라 CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어봅니다. 이때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고 Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알립니다. Allow 항목들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용됩니다. 최종적으로 Request랑 Allow가 일치하면 CORS 요청이 이루어지게됩니다.
  • 쿠키/세션에 대해 설명해주세요.
  • HTTP 프로토콜 응답 코드에 대해 설명해주세요.
    • HTTP 상태 코드라고 하며 상태 코드가 4나 5로 시작할 때 경고 알람을 보내줍니다. 상태코드는3자리의 숫자로 만들어져 있으며 상태 코드가 ‘1’로 시작하는 경우는 서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미입니다. 해당 코드는 HTTP 1.0에서 지원되지 않습니다. 2로 시작하는것은 성공을 나타내며 요청을 성공적으로 받았으며 인식했고 수용했다는 의미입니다. 3으로 시작되는 코드는 리다이렉션을 의미하며 요청 완료를 위해 추가 작업 조치가 필요하다는 의미입니다. 4로 시작하는 코드들은 클라이언트 오류를 나타내고 요청의 문법이 잘못됐거나 요청을 처리할 수 없다는 의미입니다. 5로 시작되는것도 오류를 나타내는데 서버 오류를 나타냅니다. 서버가 명백히 유효한 요청에 대한 충족을 실패했을때 해당 오류를 띄웁니다.
    • HTTP 응답 코드 중 클라이언트 에러를 나타내는 401번과 403번의 차이점을 설명해 주세요.
      • 401번은 Unauthorized로, 클라이언트가 응답을 받기 위해 권한을 가진 사용자인지 인증할 필요가 있다는 의미입니다. 403번은 Forbidden로, 클라이언트가 콘텐츠에 접근할 권리가 없음을 의미합니다. 401과 다른 점은 이 때 서버는 클라이언트가 누구인지 알고 있다는 점입니다.
  • CSRF에 대한 개념과 대응 방법은?
    • Cross-site request forgery의 약자입니다. 웹 어플링케이션 취약점 중 하나로 공격자가 의도한대로 사용자가 행동하게 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법을 의미합니다. 사용자의 요청 헤더에서 referrer 정보를 확인하여 도메인이 일치하는지 확인하고 같은 도메인에서 들어오는 접속은 허용하나 다른 도메인에서 호출할 때는 차단하는 방법으로 공격을 방어합니다. 또한 상태를 변화시키는 POST, PUT 등의 요청에 대해 CSRF 토큰이 포함되어야만 요청을 처리하는 방법으로 공격을 방어할 수도 있습니다.


  • 네트워크란 무엇이고 좋은 네트워크란 어떠한 네트워크일까요?
    • 네트워크를 평가할 때 보는 주요한 성능 지표로 delay, packet loss, throughput이 있습니다. delay는 packet을 소스로부터 목적지까지 걸리는 시간을 의미하며 짧을수록 좋습니다. packet loss는 보낸 packet중 얼마정도가 분실되었는지를 의미하며 이 또한 작을 수록 좋습니다. throughput은 전송률로 단위 시간동안 전달될 수 있는 트래픽 총량을 의미하는데 이것은 클 수록 좋은 네트워크를 의미합니다.
  • OSI 7계층과 TCP/IP 4계층의 차이점은 무엇인가요??
    • TCP/IP 계층과 달리 OSI 계층은 application 계층을 세개로 쪼개고 link 계층을 data link 계층, 물리 계층으로 나눠서 설명하는 것이 다르며, 인터넷 계층을 네트워크 계층으로 부른다는 점이 다릅니다.
  • HOL Blocking에 대해 설명해주세요
    • HOL Blocking은 Head Of Line Blocking의 약자로 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말합니다.
  • HTTP/2를 설명하고 장점 두 가지를 설명해주세요
    • HTTP/2는 HTTP/1보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선 순위 처리를 지원하는 프로토콜입니다. 장점 두가지로는 멀티플렉싱과 서버 푸시를 들겠습니다. 멀티플렉싱이란 여러 개의 스트림을 사용하여 송수신한다는 것입니다. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있습니다. 서버 푸시란 HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었다면, HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시하는 것을 말합니다. html에는 css나 js 파일이 포함되기 마련인ㄷ데 html을 읽으면서 그 안에 들어 있던 css 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있습니다.
  • www.google.com을 주소창에 입력하면 어떠한 일이 내부적으로 일어나는지 설명해 주세요
    • 사용자가 브라우저에 URL을 입력하면 DNS 서버에 도메인 네임으로 서버의 진짜 주소를 찾습니다. IP 주소로 웹 서버에 TCP 3 handshake로 연결 수립하고 클라이언트는 웹 서버로 HTTP 요청 메시지를 보냅니다. 이에 웹 서버는 HTTP 응답 메시지를 보내고 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력됩니다.


  • 공인(public) IP와 사설(private) IP의 차이에 대해 설명해주세요.
    • 공인 IP는 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소이며, 외부에 공개되어 있는 IP 주소입니다. 외부에 공개되어있기 때문에 인터넷에 연결된 다른 장비롭뭄터 접근이 가능합니다. 그에 따라 방화벽 등과 같은 보안을 설정해 주어야합니다. 사설 IP는 어떤 네트워크 안에서 사용되는 IP주소로 로컬 IP, 가상 IP라고도 합니다. 주로 일반 가정이나 회사 내 등에 할당된 네트워크 IP 주소이며, IPv4의 주소 부족으로 인해 서브넷팅 된 IP이기 때문에 라우터(공유기)에 의해 로컬 네트워크상의 PC나 장치에 할당됩니다. 사설 IP 주소만으로는 인터넷에 직접 연결할 수 없고, 라우터를 통해 1개의 공인 IP를 할당하고, 라우터에 연결된 개인 PC는 사설 IP를 각각 할당 받아 인터넷에 접속할 수 있습니다.
  • Connection Timeout과 Read Timeout의 차이에 대해 설명해주세요.
    • 서버 자체에 클라이언트가 어떤 사유로 접근을 실패했을 시 적용되는 것이 Connection timeout 입니다. 즉 접근을 시도하는 시간 제한이 connection itmeout 되는 것을 말합니다. 클라이언트가 서버에 접속을 성공 했으나 서버가 로직을 수행하는 시간이 너무 길어 제대로 응답을 못 준 상태에서 클라이언트가 연결을 해제하는 것이 read timeout입니다. 이 경우는 클라이언트는 해당 상황을 오류로 인지하고, 서버는 계속 로직을 수행하고 있어 성공으로 인지해 양 사이드간 싱크가 맞지 않아 문제가 발생할 확률이 높습니다.
  • JWT 토큰에 대해 설명해주세요
    • 간단하게 : 과거에 서버 기반 인증 시스템을 사용했습니다. 하지만 단점이 존재하여 단점을 극복하기 위해 토큰 기반 인증 시스템이 나왔습니다. 인증 받은 사용자에게 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인합니다. 서버 인증 시스템과 달리 사용자의 인증 정보를 서버에 저장하지 않고 클라이언트의 요청으로만 인가를 처리하므로 stateless한 구조를 가집니다. JWT는 Json Web Token의 약자로 인증에 필요한 정보를 암호화시킨 claim 기반의 웹 토큰을 뜻합니다. 세션/쿠키 방식과 유사하게 클라이언트는 Acess Token(JWT)을 HTTP 헤더에 실어 서버로 보냅니다.
    • 구체적으로 : 과거의 서버 기반 인증 시스템은 서버 측에서 사용자들의 정보를 기억하기 위해 세션을 유지하는데, 이는 메모리, 디스크, 데이터베이스 등을 통해 관리합니다. 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하여 유지해야 하므로 stateful한 구조를 가집니다. 중요한 정보는 서버에 있기 때문에 쿠키 자체(세션ID)에는 유의미한 값을 가지지 않아 안전하다는 장점이 있지만 해커가 훔친 쿠키를 이용해 HTTP 요청을 보내면 서버에서는 올바른 사용자가 보낸 요청인지 알 수 없다는 단점과 사용자가 증가함에 따라 과부하를 줄 수 있어 확장이 용이하지 못하다는 단점이 있습니다. 이를 해결하기 위해 토큰 기반 인증 시스템이 나왔는데 인증 받은 사용자에게 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인합니다. 서버 인증 시스템과 달리 사용자의 인증 정보를 서버에 저장하지 않고 클라이언트의 요청으로만 인가를 처리하므로 stateless한 구조를 가집니다. JWT는 Json Web Token의 약자로 인증에 필요한 정보를 암호화시킨 claim 기반의 웹 토큰을 뜻합니다. 세션/쿠키 방식과 유사하게 클라이언트는 Acess Token(JWT)을 HTTP 헤더에 실어 서버로 보냅니다. 서버 기반의 인증 시스템은 저장소의 관리가 필요하지만, 토큰 기반은 Access Token을 발급해준 후 요청이 들어오면 검증만 해주면 되기 때문에 추가 저장소가 필요 없다는 장점이 있습니다.(stateless) 또한 쿠키를 사용함으로 인해 발생하는 취약점이 사라지며 확장성이 뛰어나 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. 하지만 이미 발급된 JWT를 돌이킬 수 없어 유효기간이 완료될 때까지는 계속 사용이 가능하다는 부분과 JWT의 길이가 길어 서버의 자원 낭비가 발생할 수 있다는 단점이 존재합니다. JWT는 header, payload, signature로 구성되며 각 파트를 점으로 구분합니다. 헤더는 토큰의 타입과 해시 암호화 알고리즘으로 이루어져있고 내용은 토큰에 사용자가 담고자 하는 정보를 담습니다. 서명은 토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드입니다. 헤더와 내용의 값을 인코딩합니다.
      • Claim 기반의 웹 토큰? 일반 토큰 기반 인증은 주로 의미가 없는 문자열(random string) 기반으로 구성되어 있으며 사용할 때는 json으로 보내는 방식을 사용합니다. 단순한 문자열이므로 정보를 담거나 할 수 없으며 발급된 토큰에 대해 만료 시킬 수단이 없고 검사하거나 처리할 때마다 DB에 접근하여 검사할 경우 부담이 생깁니다. 또한 사용자 로그아웃 등으로 인한 토큰을 관리할 방법이 없습니다. 이러한 문제를 어느정도 해결할 수 있는 것이 클레임 기반 토큰 방식입니다. 클레임이란 사용자 정보나 데이터 속성을 의미합니다. 즉 토큰 안에 여러 정보를 담고있는 토큰입니다.
  • 세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.
    • 세션 기반 인증은 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 stateful한 구조를 가지고, 토큰 기반 인증은 상태 정보를 서버에 저장하지 않으므로 Stateless한 구조를 가집니다.
    • Stateful한 세션 기반의 인증 방식을 사용하게 된다면 어떠한 단점이 있을까요?
      • 서버에 세션을 저장하기 때문에 사용자가 증가하면 서버에 과부하를 줄 수 있어 확장성이 낮습니다. 또한 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다.(세션 하이재킹 공격)
    • 세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 적합한가요?
      • 단일 도메인이라면 세션 기반 인증을 사용하고, 아니라면 토큰 기반 인증을 사용하는 것이 적합하다고 생각합니다. 세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리하는 것은 어렵습니다.(CORS 문제)
  • DNS에 대해 설명해주세요.
    • domain name을 사용해 요청했을 때, 호스트의 IP주소로 변환하거나 그 반대의 변환을 수행하기 위해 개발된 시스템입니다. 또한 각각의 cllient에 요구하는 로드를 분산시켜줍니다. DNS 서버들은 계층 구조로 구현된 분산 데이터베이스로 주요 구성 요소로써 Root, Top Level Domaiin(TLD), Authoritative, Local DNS Server가 존재합니다.


  • TCP 3-way Handshake 에 대해서 설명하시오.
  • 쿠키(Cookie)와 세션(Session)을 설명하시오.
  • Socket.io와 WebSocket의 차이를 설명하시오.
    • 간단하게 : socket.io 는 상용화되어 있으며 브라우저의 종류에 상관없이 다양한 방법의 웹 기술을 실시간으로 구현할 수 있도록 한 기술입니다 web socket 은 사용할 수 있는 웹 브라우저의 종류에 제약이 있으며 미래의 기술로 아직 인터넷 기업에서 상용화 되어있진 않습니다.
    • 구체적으로 :
  • TCP와 UDP의 차이점을 설명하시오
  • Get과 Post를 설명하시오.
    • 둘 다 HTTP 프로토콜을 이용해 서버에 무언가 요청할 때 사용하는 방식입니다. GET은 데이터를 조회화기 위해 사용되는 방식으로 데이터를 헤더에 추가하여 전송하는 방식입니다. URL에 데이터가 노출되므로 보안적으로 중요한 데이터를 포함해서는 안되며 길이가 제한이 있기 때문에 전송 데이터 양이 한정되어 있고 형식에 맞지 않으면 인코딩해서 전달해야합니다. POST는 데이터를 추가 또는 수정하기 위해 사용되는 방식으로 데이터를 바디에 추가하여 전송하는 방식입니다. 파라미터가 직접적으로 노출되지 않고 길이 제한도 없습니다. 보통 GET은 서버에서 어떤 데이터를 가져와서 보여주는 용도로 활용되고 POST는 서버의 값이나 상태를 바꾸기 위해 활용됩니다.