1월 20일 월요일: 4장(3) 스터디

[kwaksj329]

4장: 커넥션 관리

곽수정: link
유미라: link
윤태연: link
최선아: link

[choiseona]

보이지 않는 네트워크가 뭔가요?

[choiseona]

보이는 네트워크 (Visible Network)

• HTTP 통신의 양 끝점에서 직접 확인할 수 있는 요소들
• ex) 클라이언트 (브라우저, 앱), 서버 (웹서버, API 서버)

보이지 않는 네트워크 (Invisible Network)

• HTTP 통신 중간에 존재하지만 직접 보이지 않는 요소들
• ex) 프록시 서버, 방화벽, NAT, 네트워크 장비들

예시

• 보이는 네트워크: 보내는 사람과 받는 사람
• 보이지 않는 네트워크: 중간 물류센터, 배송기사, 분류작업장

[kwaksj329]

중간에 구형 프락시가 있는 경우 무조건 keep-alive 연결을 못해서 Proxy-Connection이나 HTTP/1.1 개선 사항이 나오게 된걸까요?

[kwaksj329]

keep-alive 연결을 할 수는 있지만 아래와 같은 문제점이 있어 개선 방법이 등장하게 되었습니다.

1. 연결 생명주기 관리 실패
   • 연결 종료를 제때 하지 못해 고아 연결 발생
   • 타임아웃 처리 미흡으로 불필요하게 연결 유지
   • 에러 상황에서 좀비 연결 발생
2. 리소스 관리 미흡
   • 연결마다 필요한 소켓/메모리 등의 리소스를 제때 해제 못함
   • 기존 연결의 비효율적 재사용
   • 결과적으로 메모리 누수와 성능 저하 발생
3. 정책 조율 부재
   • 클라이언트/서버와의 타임아웃 정책 불일치
   • 여러 클라이언트 연결 처리시 조율 실패
   • 에러 상황에 대한 처리 정책 부재

[rhino-ty]

왜 이렇게 개발 분야에 '우아한' 이런 단어를 쓰는 걸까요?? 개발 측면에서, '우아함'이란 단어의 의미는 뭘까요?

예시)'우아하게 커넥션 종료하기', '우아하게 컴포넌트 관리하기'

[rhino-ty]

우아함이란? 간결하고 세련되며, 복잡함 속에서 단순함을 유지하는 상태. 다시 말해, 단순히 기능적 측면 뿐만 아니라, 코드의 가독성과 구조적 아름다움도 포함되는 경우를 얘기함.

• 간결성 : 최소 코드로 최대 기능 구현
• 명료성 : 직관적이고 이해하기 쉬운 코드, 변태 같이 예쁘게 쓰든가 아니면 제대로 된 디자인 패턴을 적용하든가
• 효율성 : 자원의 효과적 사용
• 재사용성 : 중복 최소화
• 확장성 : 변화에 유연한 대응

효율과 재사용을 극대화 한 사례는 40KB 안에 게임 하나 쑤셔넣기를 보면 좋음.

결론 : 기술적인 측면에서도 이러한 개념이 통용되는 단어가 됐음. 또한, 우아한 코드는 고품질 소프트웨어 개발의 핵심 요소이며, 장기적인 프로젝트 성공에 기여할 수 있음. 그래서 많이 쓰는 듯!

[ssum1ra]

현대에 구형 프록시(즉, 멍청한 프록시)가 존재한다면 발생하는 문제와 해결 방법이 무얼까요???????????????????????

[ssum1ra]

문제

• 지속 커넥션 미지원
• HTTP 헤더 누락 또는 잘못된 처리

해결 방법

• 프록시 업그레이드
• 구형 프록시의 한계에 맞춰 프로토콜이나 기능을 하향 조정

[choiseona]

파이프라인 지속커넥션에서 응답 데이터들을 큐에 모았다가 한 번에 받게 되나요 아니면 응답이 올 때마다 받게되나요?

[choiseona]

TCP의 동작 방식

• 네트워크로 전송된 데이터는 작은 패킷들로 나뉘어 전송됨
• 이 패킷들이 도착하면 일단 TCP 수신 버퍼에 저장
• 애플리케이션이 준비되면 버퍼에서 데이터를 읽어감

버퍼와 관련된 문제

• TCP 연결이 종료되면 수신 버퍼의 데이터가 모두 사라짐
• 아직 처리하지 못한 응답들이 버퍼에 있다면 모두 손실됨

[kwaksj329]

파이프라인 커넥션에서 클라이언트가 이미 커넥션이 끊긴 서버에 요청 후 에러 발생 시 왜 이전에 받았던 응답 데이터를 모두 삭제할까요?

상황: 10개 요청 전송 -> 응답들이 버퍼에 있음 -> 11번째 요청 시도 -> 서버가 연결 종료
결과:
- 'connection reset by peer' 에러 발생
- 버퍼의 이전 10개 응답 데이터 모두 삭제

[kwaksj329]

데이터의 무결성과 신뢰성을 보장하기 위해 모든 버퍼 데이터를 삭제하고, 필요하다면 새로운 연결로 처음부터 다시 요청을 시작하는 것이 안전하기 때문입니다.

HTTP 파이프라이닝의 특성

• 요청과 응답은 반드시 순서대로 처리되어야 함
• 중간에 하나라도 신뢰할 수 없으면 그 이후의 모든 응답도 신뢰할 수 없음
• 버퍼에 있는 데이터가 실제로 서버가 보낸 올바른 응답인지 확인할 방법이 없음

[ssum1ra]

서버가 병렬 처리를 해도 응답 순서가 중요한가?

[ssum1ra]

HTTP 1.1 파이프라이닝에서는 요청 순서대로 응답을 보내야 하기 때문에 가운데 요청이 지연되면 그 이후의 응답도 기다려야 하므로 전체적인 지연이 발생할 수 있다.

HTTP/2에서는 이러한 문제를 해결할 수 있는 멀티플렉싱 기능이 있다. 멀티플렉싱이란 하나의 TCP 연결 내에서 여러 요청을 동시에 처리하는 방식으로, 각 요청에 대한 응답을 독립적으로 다룰 수 있기 때문에 응답 순서에 구애받지 않는다.