A/B (Seamless) 시스템 업데이트 개요

심리스(Seamless) 업데이트라고도 하는 A/B 시스템 업데이트는 OTA (Over-The-Air) 업데이트 중에도 작동 가능한 부팅 시스템이 디스크에 남아 있도록 합니다. 이 방법은 업데이트후 장치의 비활성가능성을 줄여 주므로 수리 및 보증 센터에서 장치 교체 및 장치 리플래쉬(Reflash)가 줄어 듭니다. ChromeOS와 같은 다른 상업용 운영 체제에서도 A/B 업데이트를 성공적으로 사용됩니다.

A/B 시스템 업데이트는 다음과 같은 이점을 제공합니다.

l  OTA 업데이트는 시스템 실행중에 사용자 중단없이 발생할 수 있습니다. 사용자는 OTA도중에 장치를 계속 사용할 수 있습니다. 업데이트도중 유일한 중단 시간은 장치가 업데이트된 디스크 파티션으로 재부팅되는 경우입니다.

l  업데이트 후에는 재부팅이 일반 재부팅보다 더 소요되지 않습니다.

l  OTA가 되지 않는 경우 (예 : 불량 플래시로 인해) 사용자는 영향을 받지 않습니다. 사용자는 이전 OS를 계속 실행하며 클라이언트는 업데이트를 다시 시도할 수 있습니다.

l OTA 업데이트를 했지만 부팅에 실패하면 장치가 이전 파티션으로 재부팅되고 사용 가능한 상태로 유지됩니다. 클라이언트는 업데이트를 다시 시도할 수 있습니다.

l 오류 (예 : I/O 오류)는 사용되지 않은 파티션 세트에만 영향을 주며 재시도될 수 있습니다. 그러므로 사용자 경험을 저하시키지 않을 것입니다.

l 업데이트를 A/B 장치로 스트리밍할 수 있으므로 패키지를 설치하기 전에 다운로드할 필요가 없습니다. 스트리밍이란 사용자가 /data 또는 /cache에 업데이트 패키지를 저장할 충분한 여유 공간을 가질 필요가 없음을 의미합니다.

l 캐시 파티션은 더이상 OTA 업데이트 패키지를 저장하는데 사용되지 않으므로 캐시 파티션이 향후 업데이트를 위해 충분히 큰지 확인할 필요가 없습니다.

l dm-verity는 장치가 손상되지 않은 이미지를 부팅하도록 보장합니다. 장치가 잘못된 OTA 또는 dm-verity 문제로 인해 부팅되지 않으면 장치가 이전 이미지로 재부팅될 수 있습니다. (Android Verified Boot에는 A/B 업데이트가 필요하지 않습니다.)

A/B (Seamless) 시스템 업데이트에 대해

A/B 업데이트를 수행하려면 클라이언트와 시스템 모두를 변경해야 합니다. 그러나 OTA 패키지 서버는 변경이 필요하지 않습니다. 업데이트 패키지는 여전히 HTTPS를 통해 제공됩니다. Google의 OTA 인프라를 사용하는 기기의 경우 시스템 변경 사항이 모두 AOSP이며 클라이언트 코드는 Google Play 서비스에서 제공됩니다. Google의 OTA 인프라를 사용하지 않는 OEM은 AOSP 시스템 코드를 재사용할 수 있지만 자체 클라이언트를 제공해야 합니다.

자체 클라이언트를 제공하는 OEM의 경우 클라이언트는 다음을 수행해야 합니다.

l 업데이트를 할때를 결정합니다. A/B 업데이트가 백그라운드에서 발생하기 때문에 더이상 사용자가 시작하지 않습니다. 사용자 중단을 방지하려면 장치가 유휴 유지 관리 모드 (예 : 밤, Wi-Fi) 일때 업데이트를 예약하는 것이 좋습니다. 그러나 클라이언트는 원하는 휴리스틱(Heuristics)을 사용할 수 있습니다.

l OTA 패키지 서버에 로그린하여 업데이트를 가용한지 확인합니다. 이는 기기가 A/B를 지원한다는 신호를 보내고 싶다는 점을 제외하면 대부분 기존 클라이언트 코드와 동일해야 합니다. (Google의 고객은 사용자가 최신 업데이트를 확인하기 위해 '지금 확인' 버튼도 포함합니다.)

l 업데이트 패키지의 HTTPS URL로 update_engine을 호출합니다. update_engine은 업데이트 패키지를 스트리밍할때 현재 사용되지 않는 파티션의 블록을 업데이트합니다.

l update_engine 결과 코드에 따라 설치 성공 또는 실패를 서버에 보고합니다. 업데이트가 성공적으로 적용되면 update_engine은 다음 재부팅시 새 OS로 부팅하도록 부트 로더에 지시합니다. 새로운 OS가 부팅에 실패하면 부트 로더가 이전 OS로 대체되므로 클라이언트에서 작업할 필요가 없습니다. 업데이트가 실패하면 클라이언트는 자세한 오류 코드를 기반으로 다시 시도할 시기를 결정해야 합니다.

옵션으로 클라이언트는 다음을 수행할 수 있습니다.

l 사용자에게 재부팅하라는 알림을 표시합니다. 사용자가 정기적으로 업데이트하도록 권장하는 정책을 구현하려는 경우 이 알림을 클라이언트에 추가할 수 있습니다. 클라이언트가 사용자에게 확인 메시지를 표시하지 않으면 사용자는 다음 번에 다시 부팅할때 업데이트를 받게 됩니다.

l 사용자에게 새로운 OS 버전으로 부팅했는지 또는 이전 OS 버전으로 되돌아 갔는지 여부를 알려주는 알림을 표시합니다.

시스템 측면에서 A/B 시스템 업데이트는 다음 사항에 영향을 미칩니다.

l 파티션 선택 (슬롯), update_engine daemon 및 부트 로더 상호 작용

l 빌드 프로세스 및 OTA 업데이트 패키지 생성

JPEG XS의 개요

JPEG는 수십년 동안 이미지에 대한 압축 표준 이었지만 파일 형식은 곧 더나은 가상 현실 체험에서 더 안전한 무인 항공기 및 자가 운전 차량에 이르기까지 스트리밍하는 동안 지연 시간을 없애기 위해 설계된 JPEG XS을 곧 확보하게 될 것입니다. JPEG의 조직인 Joint Photographic Experts Group은 최근에 적은 에너지를 사용하도록 설계된 압축된 사진 및 비디오 파일 형식인 JPEG XS를 도입했습니다.

JPEG XS는 파일 크기가 실제로 JPEG보다 작지 않기 때문에 약간의 잘못된 표현입니다. 실제로 압축 파일은 더 많은 공간을 차지합니다. XS는 파일의 압축 프로세스를 나타냅니다. JPEG XS는 원본 JPEG보다 빠르고 간단하게 압축합니다. 따라서 JPEG XS는 하드 드라이브나 스마트폰에서 더 많은 공간을 차지하지만 파일은 Wi-Fi 또는 5G를 사용하여 더빨리 스트리밍됩니다. 파일이 실제로 일반 JPEG보다 크기 때문에 파일 유형은 고품질인 동시에 스트리밍 프로세스의 속도를 높입니다.

일반 조직은 JPEG를 대체하려고 하지않고 있습니다. 원본 JPEG의 작은 파일 크기는 스트리밍하지 않고 파일이 저장되는 응용프로그램에 원래의 이상적인 형태를 만듭니다. 대신 JPEG XS는 스트리밍 컨텐츠와 관련된 여러가지 문제를 완화하는 것을 목표로 합니다. 예를 들어 더 빠른 스트림을 만들어 JPEG XS는 무인 항공기 카메라가 보는 것과 무인 항공기 조종사가 실제로 같은 것을 보는 시각 사이의 지연 시간을 줄일 수 있습니다. 이와 같은 아이디어로 비슷하게 자가 운전 자동차를 더욱 안전하게 만드는데 도움이 될 수 있습니다.

그렇지만 스트림이 빨라지고 대기 시간이 짧아지는 것은 실시간 스트리밍 콘텐츠에만 국한되지 않습니다. 이 그룹은 가상 현실에서 움직임과 움직임에 대한 거의 감지할 수 없는 반응간의 지연이 일부 헤드셋 사용자가 경험에서 구역질을 느낄 수 있는 이유중 하나라고 설명합니다. 이 파일 형식을 사용하면 스마트폰에서 화면으로 (무선으로) 더 빨리 비디오를 공유할 수 있습니다.

또한 압축 속도가 빠를수록 해상도가 높아지고 8K로 스트리밍하는 것과 같이 프레임 속도가 높아질 수 있다고 합니다. 이 파일 포맷은 심지어 유럽 우주국 (European Space Agency)의 눈을 사로 잡았습니다. 이 그룹은 이 포맷이 더 적은 에너지를 사용하기 때문에 우주 프로브에서 이 포맷을 사용하는 것에 관심이 있습니다.

Touradj Ebrahimi 교수는 스위스의 기술 대학인 Ecole Polytechnique Federale De Lausanne에서 공학부의 일원으로 이 그룹의 업무를 이끌고 있습니다. "이미지 코딩의 역사에서 처음으로 우리는 품질을 더 잘 유지하기 위해 압축을 줄이고 에너지를 적게 사용하면서 프로세스를 더 빠르게 만들고 있습니다"라고 Ebrahimi는 성명서에서 말했습니다. "아이디어는 더 적은 리소스를 사용하고 더 현명하게 사용하는 것입니다. 이것은 진정한 패러다임의 변화입니다. "

원본 JPEG와 마찬가지로 JPEG XS도 오픈소스 파일 형식으로 예정되어 있습니다. 이러한 접근성은 오픈소스 때문에 보편적으로 허용되는 파일 형식이 될 수 있기 때문에 편집을 위한 형식을 고려하는 영화 및 텔레비전 학회 (Society of Motion Picture and Television Engineers)가 있습니다.

JPEG XS가 널리 채택되기 전에 국제 표준화기구 (International Organization for Standardization)는 아직 파일 형식을 승인하지 않았습니다. 일단 승인되면 Ebrahimi는 새로운 하드웨어가 이 형식을 채택할 수 있고 소프트웨어는 업데이트해야 한다고 말합니다.

"곧 JPEG XS는 영화 편집, 우주 화상 및 전문 등급 카메라와 같은 전문 응용 프로그램에 사용될 예정입니다. 자동차, 가상 현실, 증강 현실, 멀티미디어 장치와 TV 모니터 또는 프로젝터간의 무선 연결을 포함하는 가전 제품이 다음에 나올 것입니다".

"JPEG XS를 사용하려면 소비자가 차세대 장치를 보유해야 합니다. 소프트웨어 측면에서 볼때, 그들은 어쨌든 컴퓨터와 스마트폰에서 수시로 업데이트하는 것처럼 업데이트를 해야할 필요가 있습니다.".

USB 개발 역사

USB (Universal Serial Bus)는 주변 장치를 컴퓨터에 연결하기 위한 프로토콜입니다. 여러가지 유형의 하드웨어 장치를 수용할 수 있도록 설계된 표준 포트가 있습니다. 디지털 카메라, 프린터, 스캐너, 플래시 드라이브, 휴대폰, iPod 및 기타 MP3 플레이어와 같은 대부분의 최신 장치는 설계시 다양한 유향의 USB 포트를 사용합니다.

첫번째 USB 기술은 1994년에 개발되었으며, Intel의 Ajay Bhatt와 USB-IF (USB Implementers Forum, Inc)가 공동 개발했습니다. 이 조직은 Intel, Microsoft, Compaq, LSI, Apple 및 Hewlett-Packard와 같은 업계 선두 기업으로 구성됩니다. 또한 USB 기술의 모든 측면에 대한 포괄적인 사양을 지원하고 채택합니다.

USB가 출시되기 전에 컴퓨터는 직렬 및 병렬 포트를 사용하여 장치를 컴퓨터에 연결하고 데이터를 전송했습니다. 포트들은 키보드, 마우스, 조이스틱 및 프린터와 같은 주변 장치에 사용되었습니다. 장치를 연결하려면 확장 카드와 사용자 지정 드라이버가 필요했습니다. 병렬 포트는 초당 약 100KB로 데이터를 전송했으며, 직렬 포트가 115에서 450KB/초 이상으로 다양했습니다. 일부 포트들은 동시에 실행할 수 없습니다.

비호환성과 여러 인터페이스를 사용하려는 시도는 USB와 같은 기술에 대한 요구가 나타났습니다. USB와 같은 기술은 포트 유형을 6개까지 사용할 수 있게 해주었습니다. 컴퓨터를 연결 해제하거나 다시 시작할 필요없이 장치와 호스트 컴퓨터간의 즉각적인 상호 작용을 통해 USB 기술이 보다 효율적인 작동을 가능하게 합니다. 결과적으로 단일 USB 포트는 최대 127개의 장치를 처리할 수 있으며 공통의 호환성을 제공합니다.

USB 1.0은 1995년 후반에 데뷔하여 초당 12메가 비트의 속도로 데이터를 전송했습니다. 이 표준의 개정판인 USB 1.1은 초당 12메가 비트의 최고 속도로 데이터를 전송할 뿐만 아니라 저대역폭 장치에 대해 초당 1.5메가 비트의 더 낮은 속도로 작동할 수도 있습니다. 보다 효율적인 작동으로 인해 USB 1.1은 이전 제품보다 소비자가 더 많이 사용했습니다.

1998년, iMac G3은 USB를 위해 레거시 포트 (직렬 및 병렬)를 중단한 최초의 소비자용 컴퓨터였습니다. 이러한 구현은 장치용으로 다른 포트를 사용하는 것보다는 USB 주변 장치만 시장에 진출할 수 있는 길을 열었습니다. 사용 편의성, 자체 전원 공급 기능 및 USB 기술 및 장치가 제공하는 기술 사양이 결합되어 다른 포트 옵션보다 우위를 차지할 수 있었습니다.

초당 480메가 비트의 전송 속도의 USB 2.0이 2000년에 데뷔하여 다음해 공식 표준이 되었습니다. USB 2.0은 초고속 전송 속도 외에도 초당 12메가 비트 (USB 1.1 최고 속도) 및 초당 1.5메가 비트 (대역폭이 덜 필요한 마우스와 같은 장치의 경우 저속)의 두가지 느린 속도로 작동할 수 있었습니다. USB 2.0 포트는 USB 1.1 장치와 함께 작동하지만 USB 1.1 포트에는 2.0 장치와 제대로 통신 할 수 있는 대역폭 기능이 없을 수 있습니다.

USB 2.0은 다양한 멀티미디어 및 저장 장치를 위한 플러그 앤 플레이 기능을 제공합니다. 이 새 버전은 이전 버전에는 없었던 추가 사용자 기능을 제공합니다. USB 2.0은 USB 커넥터가 있는 전원 공급 장치, 다중 인터페이스를 위한 새로운 Descriptor, 그리고 두개의 장치가 다른 USB 호스트 (USB On-The-Go라고도 함)없이 상호 작용할 수 있는 기능을 추가했습니다.

2000년에는 IBM과 Trek Technology에서 처음 판매한 재기록 가능한 플러그 앤 플레이 저장 장치인 USB 플래시 드라이브도 도입되었습니다. 처음에는 최대 8메가 바이트의 데이터를 저장할 수 있었습니다. 10년이 넘어서 스토리지 용량은 단일 드라이브의 경우 256기가 바이트를 넘었습니다.

USB 플래시 드라이브의 구형 모델은 초당 12메가 비트의 최고 속도로 연결됩니다. 현재 버전은 USB 2.0을 사용하지만 NAND 플래시 기술을 사용하면 초당 480 메가 비트의 고속보다 적은 속도로 작동하지만 이전의 최고 속도 모델보다 20배 빠릅니다.

초당 최대 4.8기가 비트의 최신 버전 USB 3.0은 USB 2.0 장치 및 포트와의 역호환성을 제공합니다. USB 3.0 케이블 또는 장치가 USB 2.0 포트에 연결되어 있을 수 있지만 초고속 속도는 USB 3.0 케이블, 장치 및 포트에서만 작동합니다. USB 3.0 기술은 트래픽의 별도 와이어 레인 (2개의 전선, 전송, 2개의 전선)에서 동시에 업로드 및 다운로드할 수 있습니다. 이렇게 하면 데이터 읽기 및 쓰기 속도가 향상됩니다. 에너지를 보다 효율적으로 사용하면서 장치는 더 빠른 속도로 충전됩니다. USB 3.0은 높은 대역폭으로 최적화된 고해상도 카메라 또는 오디오 및 외장 드라이브와 같은 장치를 보다 효과적으로 작동할 수 있게 해줍니다.

무선 USB는 2007년과 2008년에 유니버설 시리즈 버스 개념을 발전시켰습니다. 프린터, 카메라, 플래시 드라이브와 같은 장치에서 데이터를 전송하고 케이블을 사용하지 않고 빠른 연결로 스트리밍 비디오를 전송하는 고 대역폭 무선 기술입니다. 무선 USB는 근거리에서 가장 잘 작동합니다. 30피트에서 초당 약 110메가 비트, 10피트에서 480메가 비트의 속도로 데이터를 전송할 수 있습니다. 무선 USB는 표준 127 장치의 연결성을 유지하면서 모바일 컴퓨팅을 위한 사용자 옵션을 확장합니다.

SSL vs. TLS - 차이점은 무엇인가?

인터넷 보안이라고 하면 SSL, TLS, ECC, SHA 등을 떠올리게 됩니다. 이러한 모든 약어는 실제로 필요한 것을 알아내는 것을 혼란스럽게 만들 수 있습니다. 아마도 가장 많이 묻는 질문은 SSL (Secure Socket Layers)과 TLS (Transport Layer Security)의 차이점입니다. 웹 사이트 (또는 다른 유형의 통신) 보안을 원하지만 SSL이 필요합니까? 아니면 TLS가 필요합니까? 아니면 모두 필요합니까?

SSL과 TLS의 간략한 역사

SSL 및 TLS는 네트워크 (예 : 웹서버에 연결하는 클라이언트)를 통해 작동하는 서버, 시스템 및 응용프로그램간에 인증 및 데이터 암호화를 제공하는 암호화 프로토콜입니다. SSL은 TLS의 이전의 프로토콜입니다. 수년동안 취약성을 해결하고 더 강력하고 안전한 암호화 제품군 및 알고리즘을 지원하기 위해 새로운 버전의 프로토콜이 출시되었습니다.

SSL은 원래 Netscape에 의해 개발되었으며 1995년 SSL 2.0 (1.0은 대중에게 공개되지 않음)을 통해 처음으로 등장했습니다. 몇가지 취약점이 발견된후 1996년에 버전 2.0이 SSL 3.0으로 빠르게 대체되었습니다. 참고로 버전 2.0 및 3.0은 때로 SSLv2 및 SSLv3으로 표기됩니다.

TLS는 1999년에 새 버전의 SSL으로서 도입되었으며 SSL 3.0을 기반으로 했습니다.

"이 프로토콜과 SSL 3.0의 차이점은 극적은 아니지만 TLS 1.0과 SSL 3.0이 상호 운용되지 않을 만큼 중요합니다."

TLS는 이전에 1.2 버전이 사용되고 있으며, 최근 국제인터넷표준화기구가 10년만에 TLS 1.3 공식 발표했습니다.

SSL 또는 TLS를 사용해야 합니까?

SSL 2.0 및 3.0 모두 IETF에 의해 사용 중지되었습니다 (각각 2011년 및 2015년). 폐기된 SSL 프로토콜 (예 : POODLE, DROWN)에서 수년동안 취약점이 발견되어 계속해서 개선되고 있습니다. 대부분의 최신 브라우저는 이전 프로토콜을 사용하는 웹서버를 만날 때 사용자 환경이 저하될 수 있습니다 (예 : URL 표시 줄의 자물쇠 또는 보안 경고). 이러한 이유로 서버 구성에서 SSL 2.0 및 3.0을 비활성화해야 하며 TLS 프로토콜만 사용하도록 설정해야 합니다.

인증서는 프로토콜과 동일하지 않습니다.

누구든지 기존 SSL 인증서를 TLS 인증서로 대체해야 한다는 걱정을 하기 전에 인증서가 프로토콜에 의존하지 않는다는 점에 유의해야 합니다. 많은 공급 업체가 "SSL / TLS 인증서"라는 문구를 사용하는 경향이 있지만 프로토콜은 인증서 자체가 아니라 서버 구성에 따라 결정되므로 "SSL 및 TLS와 함께 사용할 인증서"라고 하는 것이 더 정확할 수 있습니다.

더 많은 사람들이 익숙한 용어이기 때문에 SSL 인증서라고 하는 인증서를 계속 볼 수는 있지만 업계 전반에 TLS 용어 사용이 늘어나기 시작했습니다. SSL / TLS는 더 많은 사람들이 TLS에 익숙해질 때까지 공통적인 절충안입니다.

SSL과 TLS는 서로 다른 암호를 사용합니까?

사실, 이 질문에 대한 답은 "예"이지만, SSL 2 및 3의 역사적인 버전이나 1.1, 1.2 또는 1.3의 TLS 버전 1에 관해서도 똑같이 말할 수 있습니다. SSL과 TLS는 모두 거의 동일한 프로토콜이지만 버전 차이로 인해 SSL 2는 버전 3과 상호 운용되지 않으며 SSL 버전 3은 TLS 버전 1과 호환되지 않습니다. TLS (Transport Layer Security)는 SSL v4에 대한 새로운 이름이었지만 본질적으로 동일한 프로토콜에 대해 이야기하고 있다는 것을 불평할 수도 있습니다.

새로 출시된 프로토콜 버전은 자체 개선 및/또는 새로운 또는 향후 제공되지 않을 기능과 함께 제공될 예정입니다. SSL 버전 1은 출시되지 않았지만 버전 2는 몇가지 주요 결함이 있었으며, SSL 버전 3은 버전 2의 개정 (이러한 결함 수정)과 TLS 버전 1은 SSL 버전 3의 개선이었습니다. TLS 1.0 릴리스이후 중요성은 덜하지만, 그렇다고 중요성은 적지 않습니다.

SSL과 TLS는 단순히 클라이언트와 서버간에 발생하는 핸드 셰이크를 나타낸다는 것에 주목할 필요가 있습니다. 핸드 셰이크는 실제로 암호화 자체를 수행하지 않으며, 공유되는 비밀 및 사용될 암호화 유형을 결정하는 절차를 진행합니다.

SSL 2.0 및 3.0 사용중지

서버가 여전히 SSL 프로토콜을 지원하는지 확실하지 않으면 SSL 서버 테스트를 사용하여 쉽게 확인할 수 있습니다.

SSL 서버 테스트 : GlobalSign 서버 테스트의 결과는 활성화되었지만 없어야 하는 프로토콜을 강조 표시합니다.

"SSL과 TLS의 차이점은 무엇입니까?"라는 대화에서 많은 사람들이 SSL이라는 용어를 점점 사용하지 않습니다. 서버 구성 측면에서 볼때 취약점, 구식 암호 제품군 및 브라우저 보안 경고의 차이점이 있습니다. 서버와 관련하여 TLS 프로토콜만 사용하도록 설정해야 합니다.