-
HTTP Method와 각각 사용되는 경우를 설명해주세요.
-
세션 기반 인증과 토큰 기반 인증에 대해 설명해주세요.
-
세션 기반 인증 방식 : 사용자 인증 정보 세션 저장소에 저장
-
토큰 기반 인증(JWT)
-
쿠키와 세션의 차이를 설명해주세요.
-
Cookie
-
Session
-
TCP/UDP 차이점은? TCP/UDP를 개발단계에서 직접 사용해 본 적 있는지?
-
TCP (Transmission Control Protocol)
-
UDP (User Datagram Protocol)
-
CORS (Cross-Origin Resource Sharing)가 무엇인가요?
-
같은 출처인지 파악하는 방법
-
동작 과정
-
CORS 해결 방법
-
소켓과 웹소켓의 차이점에 대해 설명해주세요.
-
공통점
-
차이점
-
웹 소켓 탄생 이유
-
언제 사용되나요?
-
TCP에서의 3-way handshake 에 대해서 설명해주세요.
-
3-way handshake
-
4-way handshake
-
OSI 7계층은 어떻게 구성되어 있으며, 각 계층 별 데이터 전송 단위는 무엇인가요?
-
전송 단위
-
JWT란 무엇인지, 장단점에 대해서 설명해주세요.
-
주소창에 https://www.google.com/ 을 입력한 경우, 어떤 일이 발생하는지 순서대로 설명해주세요.
-
공인 IP와 사설 IP의 차이를 설명해주세요.
-
공인 IP
-
사설 IP
-
DNS에 대해 설명해주세요.
-
도메인 구성
-
동작 방식
HTTP Method와 각각 사용되는 경우를 설명해주세요.
HTTP 메소드는 클라이언트가 서버에게 사용자 요청의 목적을 알리는 수단
GET : 데이터를 조회하기 위해 사용, 데이터를 헤더에 추가하여 전송
이때, URL에 데이터가 노출되기 때문에 보안적으로 중요한 데이터를 포함해서는 안됨
POST : 데이터를 추가 또는 수정하기 위해 사용, 데이터를 바디에 추가하여 전송
완전히 안전하다는 것은 아니지만 URL에 데이터가 노출되지 않아 GET보다는 안전
PUT : 리소스가 있으면 대체하고 리소스가 없으면 생성
PUT 요청 시 요청을 일부분만 보내면 나머지는 null값으로 대체 -> 수정하지 않는 데이터도 모두 보내야 함
PATCH : PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경 가능
DELETE : 리소스를 제거할 때 사용
세션 기반 인증과 토큰 기반 인증에 대해 설명해주세요.
우선, 이러한 인증이 왜 필요한가?
-> HTTP는 본래 정보를 유지하지 않는 statless한 특성을 가져, 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요하기 때문
그리고 유저가 어떤 사이트를 이용 중일 때 유저의 권한이 필요할 때 마다 재로그인을 요구한다면 사용성이 떨어지고 매우 비효율적이라서
세션 기반 인증 방식 : 사용자 인증 정보 세션 저장소에 저장

절차
- 유저가 로그인 시 서버 메모리 상에 세션 저장
- 클라이언트의 브라우저에 쿠키로 Session Id(세션 정보 식별자) 저장
- 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송
- 서버는 클라이언트가 보낸 Session Id와 서버 메모리를 관리하고 있는 Session Id를 비교해서 일치하면 인가(Authorization)를 수행
장점
- 서버에 저장하기 때문에 관리 편하고 효율적
- 구현이 명확하여 실제 서버에서 로그인 상태 확인 유용
단점
- 서버에서 클라이언트 상태를 유지하고 있어야 하므로, 클라이언트 수가 많으면 메모리, DB 과부하가 심함
- 멀티 디바이스 환경에서 로그인 시 중복 로그인 처리가 안될 수 있음
- 사용자가 많아질 경우를 대비해 로드 밸런싱을 사용한 서버 확장 시 세션 관리 어려움
토큰 기반 인증(JWT)
절차
- 유저가 로그인을 요청하고 id, pw 정보가 유효하다면 서버에서 Secret Key를 사용해서 유저에게 토큰을 발급
- 클라이언트는 발급 받은 토큰을 저장하고, 서버에서 요청 할 때 마다, 해당 토큰을 함께 서버에 전달
- 서버에서는 토큰을 검증하고, 요청에 응답
장점
- 클라이언트에 토큰이 저장되어 있기 때문에 서버의 메모리에 부담이 되지 않으며 Scale에 있어 대비책을 고려할 필요가 없음
- 멀티 디바이스 환경에 대한 부담이 없음
단점
- 암호화가 풀릴 가능성을 배제할 수 없음
=> 암호화가 풀리더라도 토큰을 사용할 수 없도록 만료기간을 짧게 설정
(짧게는 5, 6분. 길게는 1시간) - payload 자체는 암호화 되지 않고 base64로 인코딩한 데이터이므로, 중간에 payload를 탈취하면 디코딩을 통해 데이터를 볼 수 있음
=> JWE를 통해 암호화 하거나, payload에 중요한 데이터를 넣지 않아야 한다.
jwt 어디에 저장해야될까?
JWT는 어디에 저장해야할까? - localStorage vs cookie
이번에 지하철 미션을 만들면서 JWT를 클래스 property에 저장했었는데 리뷰어 분께 해당 부분을 피드백 받으면서 어디에 JWT를 저장하는 것이 좋을까 에 대해 고민해보게 되었다. 0. 기본 지식 JWT Js
velog.io
쿠키와 세션의 차이를 설명해주세요.
Cookie
사용자가 특정 웹서버에 접속할 때 생성되는 개인 아이디와 비밀번호, 방문한 사이트의 정보를 담은 임시 파일
서버가 아닌 Client에 텍스트 파일로 저장
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송
Cookie🍪
HTTP Cookie🍪 Server에서 사용자의 컴퓨터(Client)에 저장하는 정보 파일 사용자가 별도의 요청을 하지 않아도 Browser는 request시 Request Header를 넣어 자동으로 Server에 전송 key와 value로 구성되고 String 형
no-delay.tistory.com
Session
방문자가 웹 서버에 접속해 있는 상태를 하나의 단위
브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋음
각 클라이언트에 고유 Session Id 부여
쿠키와 세션을 같이 사용하는 이유
세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있고, 속도가 느려질 수 있음
-> 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있음
캐시는 뭐야?
캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것
한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있음
TCP/UDP 차이점은? TCP/UDP를 개발단계에서 직접 사용해 본 적 있는지?
TCP (Transmission Control Protocol)
- 연결형 서비스를 지원하는 전송 계층 프로토콜 (전송 제어 프로토콜)
- 일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리함
- 패킷 사이의 순서를 보장하고, 수신 여부를 확인하는 연결지향적 가상 회선 패킷 교환 방식을 사용
- 패킷에 대한 응답으로 인한 시간 지연, CPU 소모
- 데이터 손실 시 재전송 요청
- 서버와 클라이언트 1:1 연결
- 연결(3-way handshaking) / 해제(4-way handshaking)
이러한 특징을 통해 서버와 클라이언트 간 신뢰성있는 데이터 전달과 흐름제어
예시로는 웹, 메일, 파일 전송, 터미널 접속
UDP (User Datagram Protocol)
- 데이터를 데이터그램 단위로 처리하는 비연결형 프로토콜
- 순서를 보장하지 않고 수신 여부를 확인하지 않으며 단순히 데이터만 주는 데이터그램 패킷 교환 방식을 사용
- 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 되는데 이렇게 데이터를 서로 다른 경로로 독립적으로 처리
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호 절차를 거치지 않음
- UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없음
- 소켓 대신 IP 기반으로 데이터 전송
- 흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없음
- UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없음
- 서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결될 수 있음
이러한 특징을 통해 빠른 요청과 응답 및 멀티캐스팅을 필요로 하는 작업에 유리함
예시로는 실시간 스트리밍, 음성 등
CORS (Cross-Origin Resource Sharing)가 무엇인가요?
웹 클라이언트 어플리케이션이 다른 출처에 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내는데, 이 때 브라우저는 요청 헤더에 Origin이라는 필드에 출처를 함께 담아 보낸다.
서버는 정보를 응답하면서 이 리소스에 접근하는 것이 허용된 출처를 Access-Control-Allow-Origin 필드의 값으로 보내주고, 브라우저가 자신의 Origin과 서버의 Access-Control-Allow-Origin 값을 비교해서 응답의 유효성을 평가한다.
같은 출처인지 파악하는 방법

Cross-Origin이란 다음 중 한 가지라도 다른 경우
- scheme(프로토콜) - http와 https
- host(도메인) - domain.com과 other-domain.com은 다르다.
- port(포트 번호) - 8080포트와 3000포트는 다르다.
동작 과정
- 서버로 요청을 합니다.
- 서버의 응답이 왔을 때 브라우저가 요청한 Origin과 응답한 헤더 Access-Control-Request-Headers의 값을 비교하여 유효한 요청이라면 리소스를 응답합니다. 만약 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생합니다.
CORS 해결 방법
- 서버에서 해결하기
- 응답을 보낼 때, Access-Control-Allow-Origin 헤더 값에 알맞는 값을 세팅한다.
프레임워크 등에서 이를 세팅해주는 미들웨어를 활용할 수 있다.
- 응답을 보낼 때, Access-Control-Allow-Origin 헤더 값에 알맞는 값을 세팅한다.
- 클라이언트(브라우저)에서 해결하기
- 웹 브라우저 실행 옵션이나 플러그인을 설정으로 동일 출처 정책을 우회한다.
- jsonp 방식으로 json 데이터 가져오기
- 자바스크립트 파일이나 css 파일은 동일 출처 정책에 영향을 받지 않고 가져올 수 있음
자바스크립트 파일을 가져와서 json 형식으로 파싱해 데이터를 사용할 수 있음
- 자바스크립트 파일이나 css 파일은 동일 출처 정책에 영향을 받지 않고 가져올 수 있음
소켓과 웹소켓의 차이점에 대해 설명해주세요.
Socket 프로그래밍 : Server와 Client가 특정 Port를 통해 연결을 유지하고 있어 실시간으로 양방향 통신을 할 수 있는 방식
소켓(Socket) : 네트워크상에서 동작하는 프로그램 간 통신의 종착점. 1대1 통신의 경우 양 측다 소켓이 존재해야 통신이 가능하다. 현재 대부분의 통신은 인터넷 프로토콜(TCP, UDP)에 기반하고 있으므로 대부분의 네트워크 소켓은 인터넷 소켓이다.
웹 소켓(Web Socket) : 웹소켓은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다.
최초 접속에서만 http 프로토콜 위에서 핸드쉐이킹을 하기 때문에 http 헤더를 사용한다.
HTTP나 HTTPS 위에서 동작하도록 설계되었으며, 따라서 포트는 80번 혹은 443번이다. HTTP 프로토콜과 구별은 되지만 호환이 된다.
공통점
IP와 포트를 통한 통신을 함
양방향 통신을 함
차이점
- 소켓은 TCP/IP 레이어(4계층)에서 작동하고, 웹 소켓은 HTTP 레이어(7계층)에서 작동함
- TCP에 기반한 소켓 통신은 단순히 바이트 스트림을 통한 데이터 전송이므로 바이트로 이루어진 데이터를 다룸
- 웹 소켓 통신은 7계층에 기반해 메시지 형식의 데이터 다룸.
- 프레임으로 구성된 메시지라는 논리적 단위로 송수신
- 메시지에 포함될 수 있는 교환 가능한 메시지(frame)는 텍스트와 바이너리 뿐
웹 소켓 탄생 이유
HTTP는 단방향적 구조(요청 보내면 응답이 옴)로 통신해서 TCP/IP 프로토콜을 사용하는 소켓처럼 계속 connection이 유지되는 실시간 통신을 할 수 없음 -> 이에 실시간 통신을 하고자 웹 소켓이 탄생
언제 사용되나요?
실시간 통신이 필요한 경우(여러 유저와의 같이 게임, 채팅 등등)
TCP에서의 3-way handshake 에 대해서 설명해주세요.
TCP 헤더 중 6비트로 구성된 코드 비트인 TCP 플래그가 TCP의 연결 확립 과정과 연결 종료 과정에서 중요한 역할을 함
Ugrent, Acknowledgement, Push, Reset, Synchronize, Finish가 있다. 초기값은 '0', 활성화 시 '1'
3-way handshake
3-way handshake는 TCP 연결을 위한 과정
순서
- 클라이언트에서 서버한테 연결 요청 (SYN)
- 서버에서 클라이언트한테 알겠다고 응답 (SYN, ACK)
- 클라이언트에서 연결 확립 응답 (ACK)
4-way handshake
4-way handshake는 TCP 연결 해제를 위한 과정
순서
- 클라이언트에서 서버한테 연결 해제 요청 (FIN)
- 서버에서 클라이언트한테 알겠다고 응답 (ACK)
- 서버에서도 클라이언트한테 연결 해제 요청 (FIN)
- 클라이언트에서 서버한테 알겠다고 응답 (ACK)
OSI 7계층은 어떻게 구성되어 있으며, 각 계층 별 데이터 전송 단위는 무엇인가요?
OSI 7계층 : 컴퓨터 사이에서 통신할 때 표준 프로토콜을 사용할 수 있도록 ISO에서 개발한 모델
추상화 계층 : 특정한 집합의 기능의 자세한 부분을 숨기는 한 방법
각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공
각 계층은 독립적으로 기능을 수행함
⇒ 이로써 통신이 일어나는 과정이 단계별로 파악할 수 있음
⇒ 흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽음
⇒ 7단계 중 특정한 곳에 이상이 생기면 이상이 생긴 단계만 고치면 됨
전송 단위
- 응용, 표현, 세션 : Data
- 전송 : TCP-Segment, UDP-datagram
- 네트워크 : Packet
- 데이터링크 : Frame
- 물리 : Bit
JWT란 무엇인지, 장단점에 대해서 설명해주세요.
JWT : JSON 포맷을 이용하는 Claim 기반의 웹 토큰이며, 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다.
헤더(Header).내용(Payload).서명(Signature)로 구성되며 각 파트를 점(.)으로 구분합니다.
헤더(Header) : 토큰의 타입과 해시 암호화 알고리즘(방식지정)으로 이루어져 있다.
내용(Payload) : 토큰에 사용자가 담고자 하는 정보를 담는다. 내용에는 Claim이 담겨있고, JSON(Key/Value)형태의 한 쌍으로 이루어져 있다.
서명(Signature) : 토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드이다. 헤더와 내용의 값을 인코딩한다.
출처: https://dev-coco.tistory.com/161 [슬기로운 개발생활:티스토리]
주소창에 https://www.google.com/ 을 입력한 경우, 어떤 일이 발생하는지 순서대로 설명해주세요.

순서
- 사용자가 브라우저에 URL을 입력합니다.
- DNS 서버에서 도메인 네임으로 서버의 주소를 찾습니다.
- 클라이언트는 웹 서버로 HTTP 요청 메세지를 보냅니다.
- TCP/IP 연결을 통해 HTTP 요청이 서버로 전송됨
- 웹 서버는 HTTP 응답 메세지 생성
- TCP/IP 연결을 통해 요청한 컴퓨터로 전송
- 이렇게 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력됩니다.
공인 IP와 사설 IP의 차이를 설명해주세요.
공인 IP
- 전세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP주소
- 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근이 가능하다.
- 그에 따라 방화벽 등과 같은 보안 설정을 해주어야 한다.
사설 IP
- 가정이나 회사 내에서 할당된 IP주소
- IPV4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능하기 때문에 네트워크 안에서 라우터를 통해 할당받는 가상의 주소이다.
- 별도의 설정 없이는 외부에서 접근이 불가능하다.
NAT(Network Address Translation) : 사설IP로 연결된 PC에서 외부 네트워크에 통신을 하려면 라우터가 이를 사설 IP를 공인 IP로 변환하고 응답받은 공인 IP 주소를 다시 사설 IP로 변환하는 기술
출처: https://mangkyu.tistory.com/91 [MangKyu's Diary:티스토리]
DNS에 대해 설명해주세요.
DNS : 도메인 네임 시스템으로 DNS 쿼리에 응답하고 도메인 이름을 IP 주소로 변환
DNS 서버 : 도메인 네임 시스템 서버로 도메인에 네트워크 주소를 저장하고있어서 사용자가 브라우저에 접근할 때 ip주소 대신 도메인으로 해당 주소에 접근 가능
도메인 구성
도메인 주소는 .을 기준으로 나뉘게 되며, 가장 오른쪽에서 부터 해석됩니다. 이러한 도메인 주소는 통으로 관리되는 것이 아니라, 트리 구조로 분리한 다음 관리하게 되는데, 이 전체 트리 구조를 도메인 네임 스페이스라 부르고 각각의 도메인을 네임서버가 처리하게 됩니다.
동작 방식
- 리졸버가 사용자로부터 요청 받은 도메인 네임을 가지고 네임 서버에 DNS 쿼리를 날립니다.
- 네임 서버는 해당 domain을 가지고 IP주소를 찾아 리졸버에게 넘겨줍니다.
- 리졸버는 DNS 서버로부터 최종 결과를 응답 받아 웹 브라우저로 전달합니다.
'CS' 카테고리의 다른 글
[CS 스터디] 운영체제(OS) (0) | 2024.06.18 |
---|---|
[CS] 데드락 조건, 해결 방법 (0) | 2024.06.18 |
[CS] HTTP API vs REST API (0) | 2024.05.01 |
[CS] Spring DTO (1) | 2024.05.01 |
[CS] Spring Dispatcher-Servlet (0) | 2024.05.01 |
HTTP Method와 각각 사용되는 경우를 설명해주세요.
HTTP 메소드는 클라이언트가 서버에게 사용자 요청의 목적을 알리는 수단
GET : 데이터를 조회하기 위해 사용, 데이터를 헤더에 추가하여 전송
이때, URL에 데이터가 노출되기 때문에 보안적으로 중요한 데이터를 포함해서는 안됨
POST : 데이터를 추가 또는 수정하기 위해 사용, 데이터를 바디에 추가하여 전송
완전히 안전하다는 것은 아니지만 URL에 데이터가 노출되지 않아 GET보다는 안전
PUT : 리소스가 있으면 대체하고 리소스가 없으면 생성
PUT 요청 시 요청을 일부분만 보내면 나머지는 null값으로 대체 -> 수정하지 않는 데이터도 모두 보내야 함
PATCH : PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경 가능
DELETE : 리소스를 제거할 때 사용
세션 기반 인증과 토큰 기반 인증에 대해 설명해주세요.
우선, 이러한 인증이 왜 필요한가?
-> HTTP는 본래 정보를 유지하지 않는 statless한 특성을 가져, 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요하기 때문
그리고 유저가 어떤 사이트를 이용 중일 때 유저의 권한이 필요할 때 마다 재로그인을 요구한다면 사용성이 떨어지고 매우 비효율적이라서
세션 기반 인증 방식 : 사용자 인증 정보 세션 저장소에 저장

절차
- 유저가 로그인 시 서버 메모리 상에 세션 저장
- 클라이언트의 브라우저에 쿠키로 Session Id(세션 정보 식별자) 저장
- 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송
- 서버는 클라이언트가 보낸 Session Id와 서버 메모리를 관리하고 있는 Session Id를 비교해서 일치하면 인가(Authorization)를 수행
장점
- 서버에 저장하기 때문에 관리 편하고 효율적
- 구현이 명확하여 실제 서버에서 로그인 상태 확인 유용
단점
- 서버에서 클라이언트 상태를 유지하고 있어야 하므로, 클라이언트 수가 많으면 메모리, DB 과부하가 심함
- 멀티 디바이스 환경에서 로그인 시 중복 로그인 처리가 안될 수 있음
- 사용자가 많아질 경우를 대비해 로드 밸런싱을 사용한 서버 확장 시 세션 관리 어려움
토큰 기반 인증(JWT)
절차
- 유저가 로그인을 요청하고 id, pw 정보가 유효하다면 서버에서 Secret Key를 사용해서 유저에게 토큰을 발급
- 클라이언트는 발급 받은 토큰을 저장하고, 서버에서 요청 할 때 마다, 해당 토큰을 함께 서버에 전달
- 서버에서는 토큰을 검증하고, 요청에 응답
장점
- 클라이언트에 토큰이 저장되어 있기 때문에 서버의 메모리에 부담이 되지 않으며 Scale에 있어 대비책을 고려할 필요가 없음
- 멀티 디바이스 환경에 대한 부담이 없음
단점
- 암호화가 풀릴 가능성을 배제할 수 없음
=> 암호화가 풀리더라도 토큰을 사용할 수 없도록 만료기간을 짧게 설정
(짧게는 5, 6분. 길게는 1시간) - payload 자체는 암호화 되지 않고 base64로 인코딩한 데이터이므로, 중간에 payload를 탈취하면 디코딩을 통해 데이터를 볼 수 있음
=> JWE를 통해 암호화 하거나, payload에 중요한 데이터를 넣지 않아야 한다.
jwt 어디에 저장해야될까?
JWT는 어디에 저장해야할까? - localStorage vs cookie
이번에 지하철 미션을 만들면서 JWT를 클래스 property에 저장했었는데 리뷰어 분께 해당 부분을 피드백 받으면서 어디에 JWT를 저장하는 것이 좋을까 에 대해 고민해보게 되었다. 0. 기본 지식 JWT Js
velog.io
쿠키와 세션의 차이를 설명해주세요.
Cookie
사용자가 특정 웹서버에 접속할 때 생성되는 개인 아이디와 비밀번호, 방문한 사이트의 정보를 담은 임시 파일
서버가 아닌 Client에 텍스트 파일로 저장
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송
Cookie🍪
HTTP Cookie🍪 Server에서 사용자의 컴퓨터(Client)에 저장하는 정보 파일 사용자가 별도의 요청을 하지 않아도 Browser는 request시 Request Header를 넣어 자동으로 Server에 전송 key와 value로 구성되고 String 형
no-delay.tistory.com
Session
방문자가 웹 서버에 접속해 있는 상태를 하나의 단위
브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋음
각 클라이언트에 고유 Session Id 부여
쿠키와 세션을 같이 사용하는 이유
세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있고, 속도가 느려질 수 있음
-> 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있음
캐시는 뭐야?
캐시는 이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것
한번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있는데 이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료시간을 명시하는 방법등을 이용할 수 있음
TCP/UDP 차이점은? TCP/UDP를 개발단계에서 직접 사용해 본 적 있는지?
TCP (Transmission Control Protocol)
- 연결형 서비스를 지원하는 전송 계층 프로토콜 (전송 제어 프로토콜)
- 일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리함
- 패킷 사이의 순서를 보장하고, 수신 여부를 확인하는 연결지향적 가상 회선 패킷 교환 방식을 사용
- 패킷에 대한 응답으로 인한 시간 지연, CPU 소모
- 데이터 손실 시 재전송 요청
- 서버와 클라이언트 1:1 연결
- 연결(3-way handshaking) / 해제(4-way handshaking)
이러한 특징을 통해 서버와 클라이언트 간 신뢰성있는 데이터 전달과 흐름제어
예시로는 웹, 메일, 파일 전송, 터미널 접속
UDP (User Datagram Protocol)
- 데이터를 데이터그램 단위로 처리하는 비연결형 프로토콜
- 순서를 보장하지 않고 수신 여부를 확인하지 않으며 단순히 데이터만 주는 데이터그램 패킷 교환 방식을 사용
- 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 되는데 이렇게 데이터를 서로 다른 경로로 독립적으로 처리
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호 절차를 거치지 않음
- UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없음
- 소켓 대신 IP 기반으로 데이터 전송
- 흐름제어(flow control)가 없어서 패킷이 제대로 전송되었는지, 오류가 없는지 확인할 수 없음
- UDP에는 연결 자체가 없어서(connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없음
- 서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결될 수 있음
이러한 특징을 통해 빠른 요청과 응답 및 멀티캐스팅을 필요로 하는 작업에 유리함
예시로는 실시간 스트리밍, 음성 등
CORS (Cross-Origin Resource Sharing)가 무엇인가요?
웹 클라이언트 어플리케이션이 다른 출처에 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내는데, 이 때 브라우저는 요청 헤더에 Origin이라는 필드에 출처를 함께 담아 보낸다.
서버는 정보를 응답하면서 이 리소스에 접근하는 것이 허용된 출처를 Access-Control-Allow-Origin 필드의 값으로 보내주고, 브라우저가 자신의 Origin과 서버의 Access-Control-Allow-Origin 값을 비교해서 응답의 유효성을 평가한다.
같은 출처인지 파악하는 방법

Cross-Origin이란 다음 중 한 가지라도 다른 경우
- scheme(프로토콜) - http와 https
- host(도메인) - domain.com과 other-domain.com은 다르다.
- port(포트 번호) - 8080포트와 3000포트는 다르다.
동작 과정
- 서버로 요청을 합니다.
- 서버의 응답이 왔을 때 브라우저가 요청한 Origin과 응답한 헤더 Access-Control-Request-Headers의 값을 비교하여 유효한 요청이라면 리소스를 응답합니다. 만약 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생합니다.
CORS 해결 방법
- 서버에서 해결하기
- 응답을 보낼 때, Access-Control-Allow-Origin 헤더 값에 알맞는 값을 세팅한다.
프레임워크 등에서 이를 세팅해주는 미들웨어를 활용할 수 있다.
- 응답을 보낼 때, Access-Control-Allow-Origin 헤더 값에 알맞는 값을 세팅한다.
- 클라이언트(브라우저)에서 해결하기
- 웹 브라우저 실행 옵션이나 플러그인을 설정으로 동일 출처 정책을 우회한다.
- jsonp 방식으로 json 데이터 가져오기
- 자바스크립트 파일이나 css 파일은 동일 출처 정책에 영향을 받지 않고 가져올 수 있음
자바스크립트 파일을 가져와서 json 형식으로 파싱해 데이터를 사용할 수 있음
- 자바스크립트 파일이나 css 파일은 동일 출처 정책에 영향을 받지 않고 가져올 수 있음
소켓과 웹소켓의 차이점에 대해 설명해주세요.
Socket 프로그래밍 : Server와 Client가 특정 Port를 통해 연결을 유지하고 있어 실시간으로 양방향 통신을 할 수 있는 방식
소켓(Socket) : 네트워크상에서 동작하는 프로그램 간 통신의 종착점. 1대1 통신의 경우 양 측다 소켓이 존재해야 통신이 가능하다. 현재 대부분의 통신은 인터넷 프로토콜(TCP, UDP)에 기반하고 있으므로 대부분의 네트워크 소켓은 인터넷 소켓이다.
웹 소켓(Web Socket) : 웹소켓은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다.
최초 접속에서만 http 프로토콜 위에서 핸드쉐이킹을 하기 때문에 http 헤더를 사용한다.
HTTP나 HTTPS 위에서 동작하도록 설계되었으며, 따라서 포트는 80번 혹은 443번이다. HTTP 프로토콜과 구별은 되지만 호환이 된다.
공통점
IP와 포트를 통한 통신을 함
양방향 통신을 함
차이점
- 소켓은 TCP/IP 레이어(4계층)에서 작동하고, 웹 소켓은 HTTP 레이어(7계층)에서 작동함
- TCP에 기반한 소켓 통신은 단순히 바이트 스트림을 통한 데이터 전송이므로 바이트로 이루어진 데이터를 다룸
- 웹 소켓 통신은 7계층에 기반해 메시지 형식의 데이터 다룸.
- 프레임으로 구성된 메시지라는 논리적 단위로 송수신
- 메시지에 포함될 수 있는 교환 가능한 메시지(frame)는 텍스트와 바이너리 뿐
웹 소켓 탄생 이유
HTTP는 단방향적 구조(요청 보내면 응답이 옴)로 통신해서 TCP/IP 프로토콜을 사용하는 소켓처럼 계속 connection이 유지되는 실시간 통신을 할 수 없음 -> 이에 실시간 통신을 하고자 웹 소켓이 탄생
언제 사용되나요?
실시간 통신이 필요한 경우(여러 유저와의 같이 게임, 채팅 등등)
TCP에서의 3-way handshake 에 대해서 설명해주세요.
TCP 헤더 중 6비트로 구성된 코드 비트인 TCP 플래그가 TCP의 연결 확립 과정과 연결 종료 과정에서 중요한 역할을 함
Ugrent, Acknowledgement, Push, Reset, Synchronize, Finish가 있다. 초기값은 '0', 활성화 시 '1'
3-way handshake
3-way handshake는 TCP 연결을 위한 과정
순서
- 클라이언트에서 서버한테 연결 요청 (SYN)
- 서버에서 클라이언트한테 알겠다고 응답 (SYN, ACK)
- 클라이언트에서 연결 확립 응답 (ACK)
4-way handshake
4-way handshake는 TCP 연결 해제를 위한 과정
순서
- 클라이언트에서 서버한테 연결 해제 요청 (FIN)
- 서버에서 클라이언트한테 알겠다고 응답 (ACK)
- 서버에서도 클라이언트한테 연결 해제 요청 (FIN)
- 클라이언트에서 서버한테 알겠다고 응답 (ACK)
OSI 7계층은 어떻게 구성되어 있으며, 각 계층 별 데이터 전송 단위는 무엇인가요?
OSI 7계층 : 컴퓨터 사이에서 통신할 때 표준 프로토콜을 사용할 수 있도록 ISO에서 개발한 모델
추상화 계층 : 특정한 집합의 기능의 자세한 부분을 숨기는 한 방법
각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공
각 계층은 독립적으로 기능을 수행함
⇒ 이로써 통신이 일어나는 과정이 단계별로 파악할 수 있음
⇒ 흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽음
⇒ 7단계 중 특정한 곳에 이상이 생기면 이상이 생긴 단계만 고치면 됨
전송 단위
- 응용, 표현, 세션 : Data
- 전송 : TCP-Segment, UDP-datagram
- 네트워크 : Packet
- 데이터링크 : Frame
- 물리 : Bit
JWT란 무엇인지, 장단점에 대해서 설명해주세요.
JWT : JSON 포맷을 이용하는 Claim 기반의 웹 토큰이며, 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다.
헤더(Header).내용(Payload).서명(Signature)로 구성되며 각 파트를 점(.)으로 구분합니다.
헤더(Header) : 토큰의 타입과 해시 암호화 알고리즘(방식지정)으로 이루어져 있다.
내용(Payload) : 토큰에 사용자가 담고자 하는 정보를 담는다. 내용에는 Claim이 담겨있고, JSON(Key/Value)형태의 한 쌍으로 이루어져 있다.
서명(Signature) : 토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드이다. 헤더와 내용의 값을 인코딩한다.
출처: https://dev-coco.tistory.com/161 [슬기로운 개발생활:티스토리]
주소창에 https://www.google.com/ 을 입력한 경우, 어떤 일이 발생하는지 순서대로 설명해주세요.

순서
- 사용자가 브라우저에 URL을 입력합니다.
- DNS 서버에서 도메인 네임으로 서버의 주소를 찾습니다.
- 클라이언트는 웹 서버로 HTTP 요청 메세지를 보냅니다.
- TCP/IP 연결을 통해 HTTP 요청이 서버로 전송됨
- 웹 서버는 HTTP 응답 메세지 생성
- TCP/IP 연결을 통해 요청한 컴퓨터로 전송
- 이렇게 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력됩니다.
공인 IP와 사설 IP의 차이를 설명해주세요.
공인 IP
- 전세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP주소
- 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근이 가능하다.
- 그에 따라 방화벽 등과 같은 보안 설정을 해주어야 한다.
사설 IP
- 가정이나 회사 내에서 할당된 IP주소
- IPV4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능하기 때문에 네트워크 안에서 라우터를 통해 할당받는 가상의 주소이다.
- 별도의 설정 없이는 외부에서 접근이 불가능하다.
NAT(Network Address Translation) : 사설IP로 연결된 PC에서 외부 네트워크에 통신을 하려면 라우터가 이를 사설 IP를 공인 IP로 변환하고 응답받은 공인 IP 주소를 다시 사설 IP로 변환하는 기술
출처: https://mangkyu.tistory.com/91 [MangKyu's Diary:티스토리]
DNS에 대해 설명해주세요.
DNS : 도메인 네임 시스템으로 DNS 쿼리에 응답하고 도메인 이름을 IP 주소로 변환
DNS 서버 : 도메인 네임 시스템 서버로 도메인에 네트워크 주소를 저장하고있어서 사용자가 브라우저에 접근할 때 ip주소 대신 도메인으로 해당 주소에 접근 가능
도메인 구성
도메인 주소는 .을 기준으로 나뉘게 되며, 가장 오른쪽에서 부터 해석됩니다. 이러한 도메인 주소는 통으로 관리되는 것이 아니라, 트리 구조로 분리한 다음 관리하게 되는데, 이 전체 트리 구조를 도메인 네임 스페이스라 부르고 각각의 도메인을 네임서버가 처리하게 됩니다.
동작 방식
- 리졸버가 사용자로부터 요청 받은 도메인 네임을 가지고 네임 서버에 DNS 쿼리를 날립니다.
- 네임 서버는 해당 domain을 가지고 IP주소를 찾아 리졸버에게 넘겨줍니다.
- 리졸버는 DNS 서버로부터 최종 결과를 응답 받아 웹 브라우저로 전달합니다.
'CS' 카테고리의 다른 글
[CS 스터디] 운영체제(OS) (0) | 2024.06.18 |
---|---|
[CS] 데드락 조건, 해결 방법 (0) | 2024.06.18 |
[CS] HTTP API vs REST API (0) | 2024.05.01 |
[CS] Spring DTO (1) | 2024.05.01 |
[CS] Spring Dispatcher-Servlet (0) | 2024.05.01 |