2회차 네트워크 | URL 동작 / 쿠키,세션,웹스토리지 등 기술 면접 질문 정리

24.01.05 나온 질문 정리

1번. 세션 동작방식을 설명

2번. 쿠키와 세션의 특징 및 활용 사례

3번. 쿠키와 웹 스토리지의 차이점

4번. 쿠키를 전송 시 모든 정보가 전송되는지 - 서버의 경로에 따라 필요한 데이터를 선택해서 쿠키에 담는다.

5번. 브라우저에서 URL 에서 발생하는일

6번.  3-way-handshaking 의 각 과정의 이름과 의미

7번. 쿠키와 세션의 장단점

---

네트워크 동작 과정

✅ 웹 브라우저에 www.naver.com 을 쳤을 때 생기는 과정, 그리고 DNS까지 설명해주세요.

브라우저에 **www.naver.com**을 입력했을 때 일어나는 일들을 여덟 단계로 정리할 수 있습니다.

1. 브라우저 주소창에 **www.naver.com**을 입력한다.
2. 브라우저가 **www.naver.com**의 IP 주소를 찾기 위해 캐시에서 DNS 기록을 확인한다.
3. 만약 요청한 URL( www.naver.com)이 캐시에 없다면, ISP의 DNS 서버가 DNS 쿼리로 **www.naver.com**을 호스팅하는 서버의 IP 주소를 찾는다.
4. 브라우저가 해당 서버와 TCP 연결을 시작한다.
5. 브라우저가 웹서버에 HTTP 요청을 보낸다.
6. 서버가 요청을 처리하고 응답을 보낸다.
7. 서버가 HTTP 응답을 보낸다.
8. 브라우저가 HTML 컨텐츠를 보여준다.

 

✅ DNS가 UDP를 사용하는 이유에 대해서 설명해주세요

1) 빠른 속도 : UDP는 별도 연결 설정이 없다

• TCP의 경우는 연결 위해 3 way handshake 과정이 있는 반면, UDP는 없어서 연결에 드는 비용이 줄어든다.
• 즉, 빠르다. DNS의 경우 신뢰성보다 속도가 더 중요한 서비스이므로 TCP보다 UDP 가 적합하다.

2) 연결 상태를 유지할 필요가 없다.

• TCP는 호스트 간 연결 상태를 유지한다. 연결 유지를 위해 TCP의 패킷 안에는 여러 정보가 담겨져 있다.
• 반면, UDP는 어떤 정보도 기록하지 않고 유지할 필요도 없다.
• DNS는 도메인명을 IP 주소로 변환 시 많이 사용되므로, 많은 클라이언트를 수용해야 한다.
• 따라서 연결 상태 유지 하지 않고, 정보 기록을 최소화하는 UDP가 알맞다.

---

쿠키 세션 스토리지 jwt 인증 방식 등 비교

✅ 쿠키 vs 세션 vs 토큰

• 쿠키는 브라우저에 저장되는 key-값 데이터를 말합니다 . 다만, 쿠키는 브라우저에 저장되니 제3자 조회도 가능하므로 보안에 취약합니다.
• 세션은 보안 측면에서 쿠키보다 낫습니다. 서버 측에 데이터를 저장하고, 보통 클라이언트를 구분하거나 클라이언트의 상태를 유지하기 위해 사용합니다. 그러나, 사용자 많을수록 서버에 부담줄 수 있고 속도 면에서는 느립니다.
• 토큰은 세션의 대안으로 등장했습니다. 세션과는 또 다른 유저 구분 및 상태 유지 기법입니다. 세션은 어쨋든 서버 측에 저장되기 때문에 서버 부담을 줄이기 위해 클라이언트 측에 토큰을 저장합니다. 토큰의 경우

✅ 쿠키와 세션의 차이점과 쿠키와 세션 각각의 특징을 설명해주세요

가장 큰 차이는 사용자의 정보가 저장되는 위치입니다 쿠키는 클라이언트, 세션은 서버의 자원을 사용합니다

세션은 보안이 뛰어나다는 점과 쿠키는 요청 속도가 빠르다는 특징이 있습니다.

✅ JWT (토큰)은 무엇이고 장단점에 대해 설명해주세요

Json web token 의 약자로 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰입니다.

보안성 쿠키를 전달하지 않아도 되어 취약점이 사라진다는 장점이 있지만 JWT 토큰이 길어질수록 대역폭 낭비가 심해진다는 단점이 있습니다

✅ 세션 기반 인증과 토큰 기반 인증 차이

• 세션 기반 인증은 인증 정보를 ‘서버’에 저장하는 방식 | 서버(Stateful)
• 토큰 기반 인증은 인증 정보를 ‘클라이언트’가 직접 들고 있는 방식 | 서버(Stateless)

✅ 그렇다면 Stateful한 세션 기반 인증 방식 사용하게 된다면 어떤 단점 ?

1. 서버에 세션을 저장하기 때문에 사용자 증가 시 서버에 과부하를 줄 수 있어 확장성 낮다
2. 해커가 훔친 쿠키 이용한 요청 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없다.

✅ 세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 더 적합한가 ? // 이게 먼 소리냐 ㅡㅡ

• 단일 도메인이라면 세션 기반 인증이 적합하고
• 아니라면, 토큰 기반 인증 사용이 적합하다
• 왜 ? - 세션 관리할 떄 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리하는 것은 어렵다.

CORS(Cross-Origin Resource Sharing)
웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.이러한 문제들 때문에 토큰 기반의 인증 시스템을 사용하게 되었다.

✅ JWT 토큰에 대한 설명 : JWT (Json Web Token)

• JSON 형식으로 데이터를 저장하며, 데이터의 무결성을 보장하기 위해 디지털 서명이 포함 됩니다.
• 사용자 인증 정보를 안전하게 전송하기 위해 사용
• JWT는 세션과 달리 서버 메모리는 사용 X
• 서버 확장성 용이

✅  꼬리질문) 쿠키의 장단점을 말해주세요

장점

1. 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID) 는 유의미한 값을 갖고 있지 않습니다. 중요한 정보는 서버 세션에 존재합니다.
2. 고유의 ID 값을 발급받습니다.
3. 서버의 저장공간 절약

단점

1. 보안 취약 : 요청 시 쿠키 값을 그대로 보냄
2. 작은 허용 용량 : 사이트 당 20개, 모두 합쳐 300개가 최대. 각 쿠키는 4Byte를 넘을 수 없음.
3. 웹 브라우저마다 지원 형태가 다름
4. 웹 브라우저를 변경할 경우 다른 웹브라우저에서 저장한 쿠키값을 사용할 수 없음
5. 사용자가 보안상의 문제로 거부할 경우 사용 불가능
6. 네트워크 부하 : 쿠키의 크기가 클 경우 네트워크 부하가 커짐
7. 한번에 하나의 정보만 저장할 수 있음

✅  꼬리질문) 세션의 장단점을 말해주세요

장점

1. 어느정도 보안 유지 : 최초 접속 때를 제외하고 SessionID만 사용
2. 큰 허용 용량 : 저장 개수나 용량 제한 없음(서버 용량 충분 시)
3. 서버에 저장되므로 클라이언트의 웹브라우저에 의존하지 않아도 됨
4. 데이터를 Hash Table에 저장. 한 번에 많은 정보를 하나의 세션 객체에 저장 가능
5. SessionID만 보내므로, 세션의 크기가 커도 네트워크 부하가 거의 없음

단점

1. 서버에 부하 : 서버에 데이터를 저장하므로 세션 양이 많아질수록 서버에 부하가 커짐

✅  꼬리질문) Persistence Cookie란 무엇인가요?

지속쿠키는 세션쿠키와 다르게 삭제되지 않고 더 길게 유지가 가능하다. 지속쿠키는 디스크에 저장되며, 브라우저를 닫거나 컴퓨터를 재시작해도 남아닜다. 사용자 로그인 항상 유지와 같은 곳에 사용한다.

✅  꼬리질문) Session Cookie란 무엇인가요?

사용자가 사이트 탐색 시에 관련한 설정들과 선호사항을 저장하는 임시 쿠키이다. 브라우저를 닫는 순간 삭제된다.

✅ 꼬리질문) Persistence Cookie와 Session Cookie의 차이점은 무엇인가요?

세션쿠키와 지속쿠키의 차이점은 파기시점이다. Discard라는 파라미터가 설정되어 있거나, 파기까지 남은시간인 Expires또는 Max-Age라는 파라미터가 없으면 세션쿠키이다.

✅세션의 동작 방식에 대해 설명해주세요

세션의 동작 방식으로는 다음과 같습니다.

1. 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
2. 클라이언트는 세션 ID에 대해 쿠키를 사용해 브라우저에 저장한다.
3. 클라이언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청한다.
4. 서버는 세션 ID를 전달받아 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용한다.
5. 클라이언트 정보로 서버 요청을 처리하며 클라이언트에 응답한다.

✅토큰의 과정에 대해 설명해주세요.

토큰 기반 인증 시스템을 사용하면 방문자가 자격 증명을 한 번만 확인합니다. 자격 증명이 확인되면 토큰이 할당되어 정해진 시간 동안 액세스가 가능합니다.

프로세스는 다음과 같습니다.

• 요청: 사용자가 서버 또는 보호되는 리소스에 대한 액세스를 요청합니다. 이때 비밀번호를 이용한 로그인이나 그 밖에 지정된 프로세스가 개입될 수 있습니다.
• 확인: 서버가 해당 사용자의 액세스 여부를 확인합니다. 이때는 사용자 이름에 대한 비밀번호 확인 또는 그 밖에 지정된 프로세스가 개입됩니다.
• 토큰: 서버가 링, 키, 휴대전화와 등의 인증 디바이스와 통신합니다. 확인을 마치면 서버가 토큰을 발급하여 사용자에게 전달합니다.
• 저장: 작업이 지속되는 동안 토큰이 사용자의 브라우저에 저장됩니다.

사용자가 서버에서 다른 곳에 방문하려고 하면 토큰이 서버와 다시 통신합니다. 토큰에 따라 액세스가 허용되기도 하고 거부되기도 합니다.

관리자가 토큰에 대한 사용 제한을 설정하기도 합니다. 예를들어, 사용자가 로그아웃하 지정된 시간이 지나면 토큰이 자동으로 파기되도록 설정할 수 있습니다.

✅ Access Token과 Refresh Token에 대해 설명해주세요.

Access Token(JWT)를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점입니다.

유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편합니다. 그러나 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됩니다.

이때 “그러면 유효기간을 짧게 하면서 좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 “Refresh Token”입니다.

Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다(여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미입니다.)

✅ JWT에 대해 설명해주세요

JWT(Json Web Token)은 위와 같은 일련의 과정속에서 나타난 하나의 인터넷 표준 인증 방식입니다. 말그대로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰입니다.

따라서 사실 기본적인 인증을 진행하는 구조는 Cookie때와 크게 다르지는 않습니다. 다만, 강조되는 점은 JWT는 서명된 토큰이라는 점입니다. 공개/개인 키를 쌍으로 사용하여 토큰에 서명할 경우 서명된 토큰은 개인 키를 보유한 서버가 이 서명된 토큰이 정상적인 토큰인지 인증할 수 있다는 이야기이죠.

이러한 JWT의 구조 때문에 인증 정보를 담아 안전하게 인증을 시도하게끔 전달할 수 있는 것입니다.

✅  JWT는 어떤 구조로 되어있나요?

• Header : header에는 보통 토큰의 타입이나, 서명 생성에 어떤 알고리즘이 사용되었는지 저장합니다.
• Payload : payload에는 보통 Claim이라는 사용자에 대한, 혹은 토큰에 대한 property를 key-value의 형태로 저장합니다. Claim이라는 말 그대로 토큰에서 사용할 정보의 조각입니다. 가장 중요한 것은 payload에 민감한 정보를 담지않는 것입니다. 위에 header와 payload는 json이 디코딩되어있을 뿐이지 특별한 암호화가 걸려있는 것이 아니기 때문에 누구나 jwt를 가지고 디코딩을 한다면 header나 payload에 담긴 값을 알 수 있기 때문입니다. 그래서 JWT는 단순히 “식별을 하기위한” 정보만을 담아두어야하는 것입니다.
• Signature : 가장 중요한 서명입니다. header를 디코딩한 값, payload를 디코딩한 값을 위처럼 합치고 이를 서버가 가지고 있는 개인키를 가지고 암호화되어있는 상태입니다.

✅ JWT의 장점은 무엇인가요?

1. 이미 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 인증 저장소가 “필수적”으로 필요하지 않습니다.
2. 세션과는 다르게 클라이언트의 상태를 서버가 저장해두지 않아도 됩니다.
3. signature를 공통키 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보안성이 늘어납니다.
4. 다른 서비스에 이용할 수 있는 공통적인 스펙으로써 사용할 수 있습니다.

✅  JWT의 한계점은 무엇인가요?

• 쿠키, 세션때와는 다르게 base64인코딩을 통한 정보를 전달하므로 전달량이 많다. 따라서 네트워크 전달 시 많은 데이터량으로 부하가 생길 수 있다.
• Payload에는 암호화가 되어있지 않기 때문에 민감 정보를 저장할 수 없다.
• 토큰이 탈취당하면 만료될 때까지 대처가 불가능하다.

한계점을 보안하는 가장 많이 사용하는 방법으로 JWT를 처음 발급할 때 Access Token과 함께 Refresh Token이라는 토큰을 발급하여 짧은 만료시간을 해결하는 방법입니다.