API

  1. API : application programing interface의 약자로, 어떤 프로그램에서 데이터를 주고 받기 위한 방법

  2. REST API : ★http 통신에서 어떤 자원에 대한 요청을 http메서드, 리소스, 자원의 표현(json/xml)등으로 나타내는 것을 의미합니다. 즉, http 통신 프로토콜을 이용해서 요청과 응답 메세지를 주고 받는 것을 의미합니다. (http메서드: get, post, put, delete)

  3. HTTP API 설계 법칙 :
    (1) 리소스 중심적 설계(URI는 명사를 사용): URI는 자원을 나타내는데 중점을 두어야 합니다. 보통 명사를 사용하며, 행동이나 상태를 나타내는 동사보다는 구체적인 리소스의 이름을 사용해야 합니다. 예를 들어, "/getUsers"보다는 "/users"가 좋습니다.

    (2) HTTP 메서드를 활용: HTTP에서 제공하는 메서드(GET, POST, PUT, DELETE 등)을 활용하면 리소스에 대한 행동을 명시적으로 나타낼 수 있습니다.

    (3) 상태 코드를 활용: HTTP 상태 코드는 API 응답의 결과를 표현하는 강력한 도구입니다. 일반적인 성공, 클라이언트 오류, 서버 오류 등의 상황을 표현할 수 있습니다.

  4. Request 전송 방식

GET vs Post

  1. get : 클라이언트가 서버에서 데이터를 가져올 때 사용합니다. 주소 뒤에 이름과 값이 결합된 스트링 형태로 헤더에 담아 전송하는 개념으로, 클라이언트에서 서버에 데이터를 요청할 때 사용됩니다. 빠르지만 보안에 취약하다는 단점이 있습니다.
  2. post : 클라이언트가 서버에 데이터를 전달할 때 사용됩니다. 값의 변경, 추가, 삭제 등에 이용되며 데이터를 헤더가 아닌 바디에 담아 보내기 때문에 보안적으로 get보다 우수합니다.

http vs https

  1. http : TCP와 HTTP가 직접 통신하며, 암호화를 거치지 않기 때문에 중간에서 패킷을 가로챌 수 있어 보안에 취약하다.
  2. https : TCP가 SSL과 통신하고, SSL이 HTTP와 통신하는 것이며, 중간에 암호화 계층을 거쳐서 패킷을 암호화하기 때문에 보안상 HTTP보다 더 좋다.

HTTP 프로토콜

  1. HTTP 프로토콜에 대해서 아는대로 말해주세요.

    HTTP(Hypertext Transfer Protocol)는 웹 상에서 클라이언트와 서버 간에 정보를 주고받을 수 있게 하는 프로토콜입니다. 다음과 같은 특징과 구성 요소를 가지고 있습니다.

    (1) 비연결지향 및 상태가 없음: HTTP는 요청을 전송한 후 응답을 받으면 해당 연결을 끊어버리는 비연결지향적 프로토콜입니다. 또한 각 요청이 독립적이며, 이전 요청과 후속 요청 사이에 상태 정보를 저장하지 않는 '상태가 없음'을 특징으로 가지고 있습니다. 이러한 특성 때문에 HTTP는 확장성이 높으며 대규모 트래픽을 처리할 수 있습니다. 하지만 상태를 유지하지 않기 때문에 상태 정보가 필요한 경우에는 별도의 방법으로 상태를 관리해야 하며, 이를 위해 쿠키나 세션을 활용합니다.

    (2) 요청과 응답 : HTTP 통신은 클라이언트의 요청(request)과 서버의 응답(response)로 구성됩니다. 요청은 주로 웹 브라우저에서 시작되며, HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 서버에 특정 자원을 요청하거나 정보를 전송합니다. 서버는 요청을 받아 처리 후 상태 코드(200, 404, 500 등)와 함께 응답을 반환합니다.

    (3) HTTP 메서드: HTTP는 다양한 요청 메서드를 정의하고 있습니다. 가장 흔히 사용되는 것은 GET(자원 조회), POST(자원 생성), PUT(자원 수정), DELETE(자원 삭제)입니다.

    (4) HTTP 상태 코드: HTTP 응답에는 상태 코드가 포함되어 있습니다. 이 코드는 요청이 성공적으로 처리되었는지, 클라이언트에서 잘못된 요청을 보냈는지, 서버 내부에 문제가 발생했는지 등을 나타냅니다. 예를 들어, 200은 요청이 성공적으로 처리되었음을 나타내며, 404는 요청한 자원을 찾을 수 없음을 나타냅니다.

쿠키 vs 세션 VS 캐쉬

  • 사전개념 : http는 이전 상태를 저장하지 않는 stateless의 특성과, 연결을 유지하지 않는 connectionless의 특성을 갖는다. 그렇기 때문에 웹 사이트 이용시 쿠키와 세션이 없으면 계속해서 로그인을 요구받는 상황이 발생할 수 있다. 따라서, stateless하고 connectionless한 프로토콜을 state하고 connection하게 구현하기 위한 방법이 쿠키와 세션이다.
  1. 쿠키 : 웹 사이트에 접속할 때 생성되는 정보를 웹 클라이언트에 저장하는 데이터입니다. 예를 들어 웹 사이트에서 보이는 "일주일간 보지 않기" 나 ID에 대한 비밀번호 자동 저장 등이 있습니다. 이는 서버가 아니라 클라이언트에 저장되기 때문에 가로채기 쉽고, 민감하거나 중요한 정보를 담는 것은 위험합니다.
  2. 세션 : 쿠키와 다르게 서버에 저장되는 정보로, 로그인 정보를 유지하는데 쓰입니다. 즉, 일정시간동안 로그인 상태를 유지하는 기술입니다.
    쿠키는 브라우저를 종료해도 사용자가 삭제할 때 까지 파일로 남아있고, 세션은 브라우저 종료시 삭제됩니다.
  3. 캐쉬 : 이터나 값을 미리 복사해 임시로 저장해두는 장소
  4. 로그인 과정 설명
    (1) 웹 사이트에 로그인하면, 서버는 로그인 정보가 맞는지 확인하고 맞다면 사용자에게 세션을 생성합니다. 세션은 고유한 식별자를 가지고, 서버에서 상태를 유지하는데 사용됩니다.
    (2) 서버는 세션 식별자를 쿠키에 담아 클라이언트에게 응답하고, 쿠키를 클라이언트에 저장하고 있다가 다음 요청부터는 서버에 요청할 때마다 세션 식별자를 함께 전달합니다.
    (3) 서버는 세션 식별자를 통해 이 정보가 이전 사용자 정보와 같은지 식별하고, 인증 상태를 유지합니다.
    → 서버는 고유한 세션 ID를 생성하여 쿠키값으로 만들고 헤더를 통해 웹 브라우저에 전송
    @토큰: 암호화된 접근 권한. 로그인 성공시 서버는 사용자에게 유효한 사용자라는 토큰 발행. 토큰을 가지고 여러 기능을 이용. 토큰은 인증에 필요한 정보들을 "암호화"시킨 토큰. 일정 수명이 있어서 만료되면 새로 생성해야한다.

사용자가 로그인 정보(예: 이메일과 비밀번호)를 입력하고 로그인 버튼을 클릭합니다.
서버는 사용자의 로그인 정보를 확인하고, 사용자에 대한 세션을 생성합니다. 이 세션에는 사용자의 로그인 상태와 다른 정보(예: 사용자 권한 등)를 저장합니다.
서버는 생성한 세션의 ID를 쿠키로 사용자의 브라우저에 보냅니다.
사용자가 다른 페이지를 방문하거나 새로운 요청을 보낼 때마다, 브라우저는 이 쿠키(세션 ID)를 요청 헤더에 포함시켜 서버로 보냅니다.
서버는 이 세션 ID를 확인하고, 해당 세션 정보(사용자의 로그인 상태 등)를 찾습니다. 이를 통해 사용자가 로그인 상태인지, 어떤 권한을 가지고 있는지 등을 확인할 수 있습니다.
세션을 사용하면 민감한 정보(예: 비밀번호)를 사용자의 브라우저에 저장하지 않고도 로그인 상태를 유지할 수 있습니다. 또한, 서버 측에서 세션을 관리하므로 사용자의 상태를 더 세밀하게 제어할 수 있습니다. 예를 들어, 서버는 세션을 만료시켜 사용자를 로그아웃하거나, 세션 정보를 업데이트하여 사용자의 권한을 변경할 수 있습니다.

www.naver.com을 치면 무슨 일이 일어날까요?

사용자가 브라우저에 url을 입력하면 dns서버에 도메인 네임으로 서버의 진짜 주소를 찾습니다. 그리고 IP주소로 웹 서버에 tcp 3 handshake로 연결을 수립하고 클라이언트는 웹서버로 http 요청 메세지를 보내고, 웹 서버는 http 응답 메시지를 보냅니다. 도착한 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력됩니다.
정리) DNS에서 IP주소를 가져오고, 브라우저와 서버TCP를 연결한 후,
HTTP 요청과 응답을 주고받고 브라우저에서 웹페이지를 렌더링 함

네트워크

  1. TCP 3, 4 way handshake에 대해서 설명해보세요.

    TCP 3way handshake는 가상회선을 수립하는 단계입니다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정입니다. SYN, ACK (신, 액) 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더한값을 전송합니다. 정확한 순서는 SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순으로 일어납니다.

    (왜 임의의 난수를 지정하느냐는 꼬리질문이 나올 수 있습니다. 기존 요청과 구분하기 위해서 정도로 알고있고, 그 이상은 생각해본적이 없네요.)

    TCP 4way handshake는 TCP연결을 해제하는 단계로, 클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제됩니다. 단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서는 일정시간 대기하는데, 혹시나 패킷이 나중에 도착할 수 있기 때문입니다. = time_wait이 발생하는 이유 : 클라이언트가 보낸 요청이 유실되었을 때를 대비하기 위해서.

    정리) 3WAY : 클라이언트와 서버가 세번의 패킷을 교환하며 TCP연결을 수립. 클라이언트가 서버에게 SYN패킷, 서버가 클라이언트에게 SYN-ACK패킷, 클라이언트가 서버에게 ACK 패킷
    4WAY : 클라이언트와 서버가 네번의 패킷을 교환하며 TCP연결을 종료. 클라이언트가 서버에게 FIN 패킷, 서버가 클라이언트에게 ACK패킷, 서버가 클라이언트에게 FIN패킷, 클라이언트가 서버에게 ACK패킷. 그리고 마지막 단계에 TIME_WAIT이 일어나고, 이는 잠재적인 중복 패킷이나 이전 연결의 잔여 데이터 등에 대비하기 위해 존재합니다. 즉 안정성과 신뢰성을 위해 필요한 시간입니다.

보안

  1. CSRF(크로스사이트요청위조) : 악의적인 스크립트를 이용해서 사용자가 특정한 행동을 수행하게 하는 것으로, 사용자의 패스워드를 변경하거나 게시글을 등록/삭제 하는 등의 행위가 포함됩니다다. 즉 서버쪽에 가짜 요청을 전송하게 됩니다.

  2. XSS(크로스사이트스크립팅) : 악의적인 스크립트를 이용하여 사용자의 민감 정보를 탈취하는 행위입니다.

    이 두가지 모두 스크립트 태그를 이용한 웹 해킹 공격이라는 공통점을 가집니다. XSS와 CSRF의 가장 큰 차이점은 공격이 실행되는 위치입니다. XSS는 희생자 클라이언트 PC에서 실행되며 사용자의 정보를 탈취하는 것이고, CSRF는 위조된 요청을 서버에 보내어 서버단에서 스크립트가 실행됩니다.

기타

  1. JSTL : 자바표준라이브러리의 약자로, 사용자
  2. AJAX :
  3. HTTP 멱등성, 안전성
    특정 HTTP 메서드를 여러 번 요청을 했을 경우, 매번 요청 결과가 같다면 해당 메소드를 멱등성 메소드라고 한다. GET, PUT, DELETE가 멱등성 메서드에 속하고 POST는 멱등성 메서드가 아니다.
    같은 POST를 연속적으로 보낸다면 명령은 여러 번 내린 것처럼 부가적인 결과를 가져오기 때문이다.(POST 요청을 반복하면 같은 내용이더라도 다른 데이터가 계속 추가된다.)
    GET은 여러 번 수행해도 서버의 상태가 변하지도 않고 같은 결과를 가져온다.
    PUT은 여러 번 수행해도 결과적으로 데이터는 요청한 값으로 수정된 항상 같은 상태이다.
    DELETE도 여러 번 수행해도 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에 사라진다.
    안전성은 호출해도 리소스를 변경하지 않는 특성으로 서버에 영향을 끼치는 여부로 생각하면 된다.
    GET 메서드만 안전성 메서드다.

0개의 댓글

Powered by GraphCDN, the GraphQL CDN